[要約] RFC 4353は、SIPを使用した会議のためのフレームワークを提供する。その目的は、SIPを使用して効果的な会議を実現するためのガイドラインを提供することである。
Network Working Group J. Rosenberg
Request for Comments: 4353 Cisco Systems
Category: Informational February 2006
A Framework for Conferencing with the Session Initiation Protocol (SIP)
セッション開始プロトコル（SIP）との会議のためのフレームワーク
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) The Internet Society (2006).
Copyright（C）The Internet Society（2006）。
Abstract
概要
The Session Initiation Protocol (SIP) supports the initiation, modification, and termination of media sessions between user agents. These sessions are managed by SIP dialogs, which represent a SIP relationship between a pair of user agents. Because dialogs are between pairs of user agents, SIP's usage for two-party communications (such as a phone call), is obvious. Communications sessions with multiple participants, generally known as conferencing, are more complicated. This document defines a framework for how such conferencing can occur. This framework describes the overall architecture, terminology, and protocol components needed for multi-party conferencing.
セッション開始プロトコル（SIP）は、ユーザーエージェント間のメディアセッションの開始、変更、および終了をサポートします。これらのセッションは、ユーザーエージェントのペア間のSIP関係を表すSIPダイアログによって管理されます。ダイアログはユーザーエージェントのペアの間にあるため、2者間通信（通話など）でのSIPの使用は明らかです。複数の参加者との通信セッションは、一般に会議と呼ばれ、より複雑です。このドキュメントでは、このような会議がどのように行われるかについてのフレームワークを定義しています。このフレームワークでは、マルチパーティ会議に必要な全体的なアーキテクチャ、用語、およびプロトコルコンポーネントについて説明します。
Table of Contents
目次
1. Introduction ....................................................2
2. Terminology .....................................................3
3. Overview of Conferencing Architecture ...........................6
3.1. Usage of URIs ..............................................9
4. Functions of the Elements ......................................10
4.1. Focus .....................................................10
4.2. Conference Policy Server ..................................11
4.3. Mixers ....................................................11
4.4. Conference Notification Service ...........................12
4.5. Participants ..............................................13
4.6. Conference Policy .........................................13
5. Common Operations ..............................................13
5.1. Creating Conferences ......................................13
5.2. Adding Participants .......................................14
5.3. Removing Participants .....................................15
5.4. Destroying Conferences ....................................15
5.5. Obtaining Membership Information ..........................16
5.6. Adding and Removing Media .................................16
5.7. Conference Announcements and Recordings ...................16
6. Physical Realization ...........................................18
6.1. Centralized Server ........................................18
6.2. Endpoint Server ...........................................19
6.3. Media Server Component ....................................21
6.4. Distributed Mixing ........................................22
6.5. Cascaded Mixers ...........................................24
7. Security Considerations ........................................26
8. Contributors ...................................................26
9. Acknowledgements ...............................................26
10. Informative References ........................................27
The Session Initiation Protocol (SIP) [1] supports the initiation, modification, and termination of media sessions between user agents. These sessions are managed by SIP dialogs, which represent a SIP relationship between a pair of user agents. Because dialogs are between pairs of user agents, SIP's usage for two-party communications (such as a phone call), is obvious. Communications sessions with multiple participants, however, are more complicated. SIP can support many models of multi-party communications. One, referred to as loosely coupled conferences, makes use of multicast media groups. In the loosely coupled model, there is no signaling relationship between participants in the conference. There is no central point of control or conference server. Participation is gradually learned through control information that is passed as part of the conference (using the Real Time Control Protocol (RTCP) [2], for example). Loosely coupled conferences are easily supported in SIP by using multicast addresses within its session descriptions.
セッション開始プロトコル（SIP）[1]は、ユーザーエージェント間のメディアセッションの開始、変更、および終了をサポートします。これらのセッションは、ユーザーエージェントのペア間のSIP関係を表すSIPダイアログによって管理されます。ダイアログはユーザーエージェントのペアの間にあるため、2者間通信（通話など）でのSIPの使用は明らかです。ただし、複数の参加者との通信セッションはより複雑です。 SIPは、マルチパーティ通信の多くのモデルをサポートできます。 1つは疎結合会議と呼ばれ、マルチキャストメディアグループを利用します。疎結合モデルでは、会議の参加者間にシグナリング関係はありません。中央制御ポイントや会議サーバーはありません。参加は、会議の一部として渡される制御情報を通じて徐々に学習されます（たとえば、リアルタイム制御プロトコル（RTCP）[2]を使用）。疎結合の会議は、セッションの説明内でマルチキャストアドレスを使用することにより、SIPで簡単にサポートされます。
In another model, referred to as fully distributed multiparty conferencing, each participant maintains a signaling relationship with the other participants, using SIP. There is no central point of control; it is completely distributed amongst the participants. This model is outside the scope of this document.
完全分散型マルチパーティ会議と呼ばれる別のモデルでは、各参加者はSIPを使用して他の参加者とのシグナリング関係を維持します。制御の中心点はありません。参加者の間で完全に配布されます。このモデルはこのドキュメントの範囲外です。
In another model, sometimes referred to as the tightly coupled conference, there is a central point of control. Each participant connects to this central point. It provides a variety of conference functions, and may possibly perform media mixing functions as well. Tightly coupled conferences are not directly addressed by RFC 3261, although basic participation is possible without any additional protocol support.
密結合会議と呼ばれることもある別のモデルでは、制御の中心点があります。各参加者はこの中心点に接続します。さまざまな会議機能を提供し、メディアミキシング機能も実行する可能性があります。緊密に結合された会議は、RFC 3261で直接対処されていませんが、追加のプロトコルサポートがなくても基本的な参加は可能です。
This document presents the overall framework for tightly coupled SIP conferencing, referred to simply as "conferencing" from this point forward. This framework presents a general architectural model for these conferences and presents terminology used to discuss such conferences. It also discusses the ways in which SIP itself is involved in conferencing. The aim of the framework is to meet the general requirements for conferencing that are outlined in [3]. This specification alludes to non-SIP-specific mechanisms for achieving several conferencing functions. Those mechanisms are outside the scope of this specification.
このドキュメントでは、密に結合されたSIP会議の全体的なフレームワークについて説明します。以降、これを単に「会議」と呼びます。このフレームワークは、これらの会議の一般的なアーキテクチャモデルを示し、そのような会議の説明に使用される用語を示します。また、SIP自体が会議に関与する方法についても説明します。フレームワークの目的は、[3]で概説されている会議の一般的な要件を満たすことです。この仕様は、いくつかの会議機能を実現するための非SIP固有のメカニズムに言及しています。これらのメカニズムは、この仕様の範囲外です。
Conference: Conference is an overused term, which has different meanings in different contexts. In SIP, a conference is an instance of a multi-party conversation. Within the context of this specification, a conference is always a tightly coupled conference.
会議：会議は使い古された用語であり、コンテキストによって意味が異なります。 SIPでは、会議はマルチパーティ会話のインスタンスです。この仕様のコンテキスト内では、会議は常に密結合の会議です。
Loosely Coupled Conference: A loosely coupled conference is a conference without coordinated signaling relationships amongst participants. Loosely coupled conferences frequently use multicast for distribution of conference memberships.
疎結合の会議：疎結合の会議は、参加者間の調整されたシグナリング関係のない会議です。疎結合の会議では、会議のメンバーシップの配布にマルチキャストがよく使用されます。
Tightly Coupled Conference: A tightly coupled conference is a conference in which a single user agent, referred to as a focus, maintains a dialog with each participant. The focus plays the role of the centralized manager of the conference, and is addressed by a conference URI.
密結合会議：密結合会議は、フォーカスと呼ばれる単一のユーザーエージェントが各参加者とのダイアログを維持する会議です。フォーカスは、会議の集中管理者の役割を果たし、会議URIによって対処されます。
Focus: The focus is a SIP user agent that is addressed by a conference URI and identifies a conference (recall that a conference is a unique instance of a multi-party conversation). The focus maintains a SIP signaling relationship with each participant in the conference. The focus is responsible for ensuring, in some way, that each participant receives the media that make up the conference. The focus also implements conference policies. The focus is a logical role.
フォーカス：フォーカスは、会議URIによってアドレス指定され、会議を識別するSIPユーザーエージェントです（会議はマルチパーティ会話の一意のインスタンスであることを思い出してください）。フォーカスは、会議の各参加者とのSIPシグナリング関係を維持します。フォーカスは、何らかの形で、各参加者が会議を構成するメディアを受け取ることを保証する責任があります。焦点は、会議ポリシーも実装します。焦点は論理的な役割です。
Conference URI: A URI, usually a SIP URI, that identifies the focus of a conference.
会議URI：会議の焦点を識別するURI（通常はSIP URI）。
Participant: The software element that connects a user or automata to a conference. It implements, at a minimum, a SIP user agent, but may also implement non-SIP-specific mechanisms for additional functionality.
参加者：ユーザーまたはオートマトンを会議に接続するソフトウェア要素。少なくともSIPユーザーエージェントを実装しますが、追加機能のためにSIP固有でないメカニズムを実装することもできます。
Conference State: The state of the conference includes the state of the focus, the set of participants connected to the conference, and the state of their respective dialogs.
会議の状態：会議の状態には、フォーカスの状態、会議に接続している参加者のセット、およびそれぞれのダイアログの状態が含まれます。
Conference Notification Service: A conference notification service is a logical function provided by the focus. The focus can act as a notifier [4], accepting subscriptions to the conference state, and notifying subscribers about changes to that state.
会議通知サービス：会議通知サービスは、フォーカスによって提供される論理機能です。フォーカスは通知機能として機能し[4]、会議状態へのサブスクリプションを受け入れ、その状態への変更についてサブスクライバーに通知します。
Conference Policy Server: A conference policy server is a logical function that can store and manipulate the conference policy. This logical function is not specific to SIP, and may not physically exist. It refers to the component that interfaces a protocol to the conference policy.
会議ポリシーサーバー：会議ポリシーサーバーは、会議ポリシーを保存および操作できる論理機能です。この論理機能はSIPに固有のものではなく、物理的に存在しない場合があります。これは、プロトコルを会議ポリシーにインターフェースするコンポーネントを指します。
Conference Policy: The complete set of rules governing a particular conference.
会議ポリシー：特定の会議を管理する一連の完全なルール。
Mixer: A mixer receives a set of media streams of the same type, and combines their media in a type-specific manner, redistributing the result to each participant. This includes media transported using RTP [2]. As a result, the term defined here is a superset of the mixer concept defined in RFC 3550, since it allows for non-RTP-based media such as instant messaging sessions [5].
ミキサー：ミキサーは、同じタイプのメディアストリームのセットを受け取り、タイプ固有の方法でメディアを組み合わせて、結果を各参加者に再配布します。これには、RTPを使用して転送されるメディアが含まれます[2]。結果として、ここで定義されている用語は、インスタントメッセージングセッションなどの非RTPベースのメディアを許可するため、RFC 3550で定義されているミキサーの概念のスーパーセットです[5]。
Conference-Unaware Participant: A conference-unaware participant is a participant in a conference that is not aware that it is actually in a conference. As far as the UA is concerned, it is a point-to-point call.
会議に対応していない参加者：会議に対応していない参加者は、実際に会議に参加していることを認識していない会議の参加者です。 UAに関する限り、それはポイントツーポイントコールです。
Cascaded Conferencing: A mechanism for group communications in which a set of conferences are linked by having their focuses interact in some fashion.
カスケードされた会議：グループ通信のメカニズム。会議のセットは、フォーカスを何らかの方法で相互作用させることによってリンクされます。
Simplex Cascaded Conferences: a group of conferences that are linked such that the user agent that represents the focus of one conference is a conference-unaware participant in another conference.
シンプレックスカスケード会議：ある会議の焦点を表すユーザーエージェントが別の会議の会議を認識しない参加者になるようにリンクされた会議のグループ。
Conference-Aware Participant: A conference-aware participant is a participant in a conference that has learned, through automated means, that it is in a conference. A conference-aware participant can use the conference notification service or additional non-SIP-specific mechanisms for additional functionality.
会議対応参加者：会議対応参加者とは、自動化された方法で会議に参加していることを学習した会議の参加者です。会議対応の参加者は、会議通知サービスまたは追加機能のSIP固有でない追加メカニズムを使用できます。
Conference Server: A conference server is a physical server that contains, at a minimum, the focus. It may also include a conference policy server and mixers.
会議サーバー：会議サーバーは、少なくともフォーカスを含む物理サーバーです。また、会議ポリシーサーバーとミキサーが含まれる場合もあります。
Mass Invitation: An attempt to add a large number of users into a conference.
大量招待：会議に多数のユーザーを追加する試み。
Mass Ejection: An attempt to remove a large number of users from a conference.
大量排除：会議から多数のユーザーを削除する試み。
Sidebar: A sidebar appears to the users within the sidebar as a "conference within the conference". It is a conversation amongst a subset of the participants to which the remaining participants are not privy.
サイドバー：サイドバーは、サイドバー内のユーザーに「会議内の会議」として表示されます。それは、残りの参加者が特権を持たない参加者のサブセット間の会話です。
Anonymous Participant: An anonymous participant is one that is known to other participants through the conference notification service, but whose identity is being withheld.
匿名の参加者：匿名の参加者とは、会議通知サービスを通じて他の参加者に知られているが、その身元が隠されている参加者です。
+-----------+
| |
| |
|Participant|
| 4 |
| |
+-----------+
|
|SIP
|Dialog
|4
|
+-----------+ +-----------+ +-----------+
| | | | | |
| | | | | |
|Participant|-----------| Focus |------------|Participant|
| 1 | SIP | | SIP | 3 |
| | Dialog | | Dialog | |
+-----------+ 1 +-----------+ 3 +-----------+
|
|
|SIP
|Dialog
|2
|
+-----------+
| |
| |
|Participant|
| 2 |
| |
+-----------+
Figure 1
図1
The central component (literally) in a SIP conference is the focus. The focus maintains a SIP signaling relationship with each participant in the conference. The result is a star topology, as shown in Figure 1.
SIP会議の（文字通り）中心的なコンポーネントが焦点です。フォーカスは、会議の各参加者とのSIPシグナリング関係を維持します。その結果、図1に示すように、スタートポロジになります。
The focus is responsible for making sure that the media streams that constitute the conference are available to the participants in the conference. It does that through the use of one or more mixers, each of which combines a number of input media streams to produce one or more output media streams. The focus uses the media policy to determine the proper configuration of the mixers.
フォーカスは、会議を構成するメディアストリームを会議の参加者が確実に利用できるようにする責任があります。これは、1つ以上のミキサーを使用することによって行われます。ミキサーのそれぞれは、いくつかの入力メディアストリームを組み合わせて、1つ以上の出力メディアストリームを生成します。焦点は、メディアポリシーを使用して、ミキサーの適切な構成を決定します。
The focus has access to the conference policy, an instance of which exists for each conference. Effectively, the conference policy can be thought of as a database that describes the way that the conference should operate. It is the responsibility of the focus to enforce those policies. Not only does the focus need read access to the database, but it needs to know when it has changed. Such changes might result in SIP signaling (for example, the ejection of a user from the conference using BYE), and those changes that affect the conference state will require a notification to be sent to subscribers using the conference notification service.
フォーカスは会議ポリシーにアクセスでき、そのインスタンスは各会議に存在します。事実上、会議のポリシーは、会議の運営方法を記述するデータベースと考えることができます。これらのポリシーを実施することは、フォーカスの責任です。フォーカスはデータベースへの読み取りアクセスを必要とするだけでなく、いつ変更されたかを知る必要があります。このような変更により、SIPシグナリング（BYEを使用した会議からのユーザーの退出など）が発生する可能性があり、会議の状態に影響を与える変更では、会議通知サービスを使用してサブスクライバーに通知を送信する必要があります。
The conference is represented by a URI that identifies the focus. Each conference has a unique focus and a unique URI identifying that focus. Requests to the conference URI are routed to the focus for that specific conference.
会議は、フォーカスを識別するURIで表されます。各会議には、一意のフォーカスと、そのフォーカスを識別する一意のURIがあります。会議URIへの要求は、その特定の会議のフォーカスにルーティングされます。
Users usually join the conference by sending an INVITE to the conference URI. As long as the conference policy allows, the INVITE is accepted by the focus and the user is brought into the conference. Users can leave the conference by sending a BYE, as they would in a normal call.
ユーザーは通常、INVITEを会議URIに送信して会議に参加します。会議ポリシーが許可する限り、INVITEはフォーカスによって受け入れられ、ユーザーは会議に参加します。ユーザーは、通常の通話と同じように、BYEを送信することで会議から退出できます。
Similarly, the focus can terminate a dialog with a participant, should the conference policy change to indicate that the participant is no longer allowed in the conference. A focus can also initiate an INVITE to bring a participant into the conference.
同様に、参加者が会議に参加できなくなったことを会議ポリシーが変更した場合、フォーカスは参加者とのダイアログを終了できます。フォーカスは、INVITEを開始して、参加者を会議に参加させることもできます。
The notion of a conference-unaware participant is important in this framework. A conference-unaware participant does not even know that the UA it is communicating with happens to be a focus. As far as it's concerned, the UA appears like any other UA. The focus, of course, knows that it's a focus, and it performs the tasks needed for the conference to operate.
このフレームワークでは、会議を意識しない参加者の概念が重要です。会議に対応していない参加者は、自分が通信しているUAがフォーカスされていることさえ知りません。それに関する限り、UAは他のUAと同じように見えます。もちろん、フォーカスはそれがフォーカスであることを知っており、会議の運営に必要なタスクを実行します。
Conference-unaware participants have access to a good deal of functionality. They can join and leave conferences using SIP, and obtain more advanced features through stimulus signaling, as discussed in [6]. However, if the participant wishes to explicitly control aspects of the conference using functional signaling protocols, the participant must be conference-aware.
会議に対応していない参加者は、多くの機能にアクセスできます。 [6]で説明されているように、SIPを使用して会議に参加したり、会議から脱退したり、刺激シグナリングを介してより高度な機能を取得したりできます。ただし、参加者が機能的なシグナリングプロトコルを使用して会議の側面を明示的に制御する場合は、参加者が会議に対応している必要があります。
.....................................
. .
. .
. .
. .
. .
. .
. .
. +-----------+ //-----\\ .
. | | || || .
non-SIP . | Conference| \\-----// .
+---------------->| Policy | | | .
| . | Server |----> | | .
| . | | |Conference| .
| . +-----------+ | Policy | .
| . | | .
| . | | .
+-----------+ . +-----------+ | | .
| | . | | \ // .
| | . | | \-----/ .
|Participant|<--------->| Focus | | .
| | SIP . | | | .
| | Dialog . | |<-----------+ .
+-----------+ . |...........| .
^ . | Conference| .
| . |Notification .
+------------>| Service | .
Subscription. +-----------+ .
. .
. .
. .
. .
.....................................
Conference Functions
会議機能
Figure 2
図2
A conference-aware participant is one that has access to advanced functionality through additional protocol interfaces, which may include access to the conference policy through non-SIP-specific mechanisms. A model for this interaction is shown in Figure 2. The participant can interact with the focus using extensions, such as REFER, in order to access enhanced call control functions [7]. The participant can SUBSCRIBE to the conference URI, and be connected to the conference notification service provided by the focus. Through this mechanism, it can learn about changes in participants - effectively, the state of the dialogs and the media.
会議対応の参加者とは、追加のプロトコルインターフェイスを介して高度な機能にアクセスできる参加者であり、SIP固有でないメカニズムを介した会議ポリシーへのアクセスが含まれる場合があります。この対話のモデルを図2に示します。参加者は、拡張されたコール制御機能にアクセスするために、REFERなどの拡張機能を使用してフォーカスと対話できます[7]。参加者は、会議URIをサブスクライブして、フォーカスによって提供される会議通知サービスに接続できます。このメカニズムを通じて、参加者の変化、つまり対話やメディアの状態を効果的に知ることができます。
The participant can communicate with the conference policy server using some kind of non-SIP-specific mechanism by which it can affect the conference policy. The conference policy server need not be available in any particular conference, although there is always a conference policy.
参加者は、会議ポリシーに影響を与えることができる、SIP固有でない何らかのメカニズムを使用して、会議ポリシーサーバーと通信できます。会議ポリシーサーバーは常に特定の会議で使用できる必要はありませんが、常に会議ポリシーが存在します。
The interfaces between the focus and the conference policy, and between the conference policy server and the conference policy are non-SIP-specific. For the purposes of SIP-based conferencing, they serve as logical roles involved in a conference, as opposed to representing a physical decomposition. The separation of these functions is documented here to encourage clarity in the requirements. This approach provides individual SIP implementations the flexibility to compose a conferencing system in a scalable and robust manner without requiring the complete development of these interfaces.
フォーカスと会議ポリシーの間、および会議ポリシーサーバーと会議ポリシーの間のインターフェイスは、SIP固有ではありません。 SIPベースの会議では、物理的な分解を表すのではなく、会議に関与する論理的な役割を果たします。これらの機能の分離は、要件を明確にするためにここに記載されています。このアプローチは、個々のSIP実装に、これらのインターフェースの完全な開発を必要とせずに、スケーラブルで堅牢な方法で会議システムを構成する柔軟性を提供します。
It is fundamental to this framework that a conference is uniquely identified by a URI, and that this URI identifies the focus that is responsible for the conference. The conference URI is unique, such that no two conferences have the same conference URI. A conference URI is always a SIP or SIPS URI.
会議がURIによって一意に識別され、このURIが会議を担当するフォーカスを識別することが、このフレームワークの基本です。会議URIは一意であり、2つの会議が同じ会議URIを持つことはありません。会議URIは常にSIPまたはSIPS URIです。
The conference URI is opaque to any participants that might use it. There is no way to look at the URI and know for certain whether it identifies a focus, as opposed to a user or an interface on a PSTN gateway. This is in line with the general philosophy of URI usage [8]. However, contextual information surrounding the URI (for example, SIP header parameters) may indicate that the URI represents a conference.
会議URIは、それを使用する可能性のあるすべての参加者に対して不透明です。 PSTNゲートウェイ上のユーザーまたはインターフェイスとは対照的に、URIを見て、それがフォーカスを識別するかどうかを確実に知る方法はありません。これは、URIの使用に関する一般的な哲学と一致しています[8]。ただし、URIを囲むコンテキスト情報（たとえば、SIPヘッダーパラメーター）は、URIが会議を表すことを示す場合があります。
When a SIP request is sent to the conference URI, that request is routed to the focus, and only to the focus. The element or system that creates the conference URI is responsible for guaranteeing this property.
SIP要求が会議URIに送信されると、その要求はフォーカスにルーティングされ、フォーカスのみにルーティングされます。会議URIを作成する要素またはシステムは、このプロパティを保証する責任があります。
The conference URI can represent a long-lived conference or interest group, such as "sip:discussion-on-dogs@example.com". The focus identified by this URI would always exist, and always be managing the conference for whatever participants are currently joined. Other conference URIs can represent short-lived conferences, such as an ad-hoc conference.
会議URIは、「sip：discussion-on-dogs@example.com」のように、存続期間の長い会議またはインタレストグループを表すことができます。このURIで識別されるフォーカスは常に存在し、現在参加している参加者の会議を常に管理しています。他の会議URIは、アドホック会議などの短期間の会議を表すことができます。
Ideally, a conference URI is never constructed or guessed by a user. Rather, conference URIs are learned through many mechanisms. A conference URI can be emailed or sent in an instant message. A conference URI can be linked on a web page. A conference URI can also be obtained from some non-SIP mechanism.
理想的には、ユーザーが会議URIを構築または推測することはありません。むしろ、会議URIは多くのメカニズムを通じて学習されます。会議URIは、電子メールで送信するか、インスタントメッセージで送信できます。会議URIはWebページにリンクできます。会議URIは、一部の非SIPメカニズムから取得することもできます。
To determine that a SIP URI does represent a focus, standard techniques for URI capability discovery can be used. Specifically, the callee capabilities specification [9] provides the "isfocus" feature tag to indicate that the UA is acting as focus in this dialog. Callee capability parameters are also used to indicate that a focus supports the conference notification service. This is done by declaring support for the SUBSCRIBE method and the relevant package(s) in the caller preferences feature parameters associated with the conference URI.
SIP URIがフォーカスを表していると判断するために、URI機能ディスカバリーの標準的な手法を使用できます。具体的には、呼び出し先機能仕様[9]は、「isfocus」機能タグを提供して、UAがこのダイアログでフォーカスとして機能していることを示します。呼び出し先機能パラメータは、フォーカスが会議通知サービスをサポートすることを示すためにも使用されます。これは、会議URIに関連付けられた発信者設定機能パラメーターでSUBSCRIBEメソッドと関連パッケージのサポートを宣言することによって行われます。
Other functions in a conference may be represented by URIs. If the conference policy is exposed through a web application, it is identified by an HTTP URI. If it is accessed using an explicit protocol, it is a URI defined for that protocol.
会議の他の機能は、URIで表すことができます。会議ポリシーがWebアプリケーションを介して公開される場合、それはHTTP URIによって識別されます。明示的なプロトコルを使用してアクセスされる場合、それはそのプロトコルに対して定義されたURIです。
Starting with the conference URI, the URIs for the other logical entities in the conference can be learned using the conference notification service.
会議URIから始めて、会議の他の論理エンティティのURIは、会議通知サービスを使用して学習できます。
This section gives a more detailed description of the functions typically implemented in each of the elements.
このセクションでは、各要素で通常実装される機能の詳細について説明します。
As its name implies, the focus is the center of the conference. All participants in the conference are connected to it by a SIP dialog. The focus is responsible for maintaining the dialogs connected to it. It ensures that the dialogs are connected to a set of participants who are allowed to participate in the conference, as defined by the membership policy. The focus also uses SIP to manipulate the media sessions, in order to make sure each participant obtains all the media for the conference. To do that, the focus makes use of mixers.
その名前が示すように、焦点は会議の中心です。会議のすべての参加者は、SIPダイアログによって会議に接続されます。フォーカスはそれに接続されているダイアログを維持する責任があります。これにより、ダイアログは、メンバーシップポリシーで定義されているように、会議への参加を許可された一連の参加者に確実に接続されます。フォーカスでは、各参加者が会議のすべてのメディアを確実に取得するために、SIPを使用してメディアセッションを操作します。そのために、焦点はミキサーを利用します。
When a focus receives an INVITE, it checks the conference policy. The policy might indicate that this participant is not allowed to join, in which case the call can be rejected. It might indicate that another participant, acting as a moderator, needs to approve this new participant. In that case, the INVITE might be parked on a music-on-hold server, or a 183 response might be sent to indicate progress. A notification, using the conference notification service, would be sent to the moderator. The moderator could then allow this new participant to join, and the focus could then accept the INVITE (or unpark it from the music-on-hold server). The interpretation of policy by the focus is, itself, a matter of local policy, and not subject to standardization.
フォーカスがINVITEを受信すると、会議ポリシーを確認します。このポリシーは、この参加者が参加を許可されていないことを示している場合があります。その場合、通話は拒否されます。モデレーターとして機能している別の参加者がこの新しい参加者を承認する必要があることを示している可能性があります。その場合、INVITEは保留音サーバーに保留されるか、183応答が送信されて進行状況を示します。会議通知サービスを使用した通知がモデレーターに送信されます。次に、モデレーターはこの新しい参加者の参加を許可し、フォーカスはINVITEを受け入れる（または保留音楽サーバーからパーク解除する）ことができます。焦点によるポリシーの解釈は、それ自体、ローカルポリシーの問題であり、標準化の対象ではありません。
When it is necessary to remove a SIP participant (with a confirmed dialog) from a conference, the focus would send a BYE to that participant to remove the participant. This is often referred to as "ejecting" a user from the conference, and is called "mass ejection" when done for many users. Similarly, if it is necessary to add a new SIP participant to a conference, the focus would send an INVITE request to that participant. When done for a large number of users, this is called mass invitation. Finally, if it is necessary to change the properties of the media of a session (for example to remove video) for a SIP participant, the focus can update the session description for that participant by sending a re-INVITE or UPDATE [15] request with a new offer to that participant.
会議からSIPダイアログの参加者（確認済みのダイアログが表示されている）を削除する必要がある場合、フォーカスはその参加者にBYEを送信して参加者を削除します。これは多くの場合、ユーザーを会議から「退出させる」と呼ばれ、多くのユーザーに対して行われる場合は「大量退出」と呼ばれます。同様に、新しいSIP参加者を会議に追加する必要がある場合、フォーカスはその参加者にINVITE要求を送信します。多数のユーザーに対して行われる場合、これは大量招待と呼ばれます。最後に、SIP参加者のセッションのメディアのプロパティを変更する必要がある場合（ビデオを削除するなど）、フォーカスはre-INVITEまたはUPDATE [15]リクエストを送信することにより、その参加者のセッションの説明を更新できます。その参加者への新しいオファーで。
In many cases, the signaling actions performed by the focus, such as ejection or addition of a participant, will change the media composition of the conference. To affect these changes, the focus interacts with the mixer. Through that interaction, it makes sure that all valid participants received a copy of the media streams, and that each participant sends media to an IP address and port on the mixer that cause it to be appropriately mixed with the other media in the conference. The means by which the focus interacts with the mixer are outside the scope of this specification.
多くの場合、参加者の退出や追加など、フォーカスによって実行されるシグナリングアクションは、会議のメディア構成を変更します。これらの変更に影響を与えるために、フォーカスはミキサーと相互作用します。この相互作用により、有効な参加者全員がメディアストリームのコピーを受信し、各参加者がメディアをミキサーの他のメディアと適切に混合させるミキサーのIPアドレスとポートに送信することが保証されます。フォーカスがミキサーと相互作用する方法は、この仕様の範囲外です。
The conference policy server is a logical component of the system. It represents the interface between clients and the conference policy that governs the operation of the conference. Clients communicate with the conference policy server using a non-SIP-specific mechanism.
会議ポリシーサーバーは、システムの論理コンポーネントです。これは、クライアントと会議の運営を管理する会議ポリシーとの間のインターフェースを表します。クライアントは、SIP固有でないメカニズムを使用して会議ポリシーサーバーと通信します。
A mixer is responsible for combining the media streams that make up the conference, and generating one or more output streams that are distributed to recipients (which could be participants or other mixers). The process of combining media is specific to the media type, and is directed by the focus, under the guidance of the rules described in the media policy.
ミキサーは、会議を構成するメディアストリームを結合し、受信者（参加者や他のミキサーである可能性があります）に配信される1つ以上の出力ストリームを生成します。メディアを組み合わせるプロセスはメディアタイプに固有であり、メディアポリシーに記載されているルールのガイダンスの下で、フォーカスによって指示されます。
A mixer is not aware of a "conference" as an entity, per se. A mixer receives media streams as inputs, and based on directions provided by the focus, generates media streams as outputs. There is no grouping of media streams beyond the policies that describe the ways in which the streams are mixed.
ミキサー自体は、エンティティとしての「会議」を認識していません。ミキサーはメディアストリームを入力として受け取り、フォーカスによって提供される指示に基づいて、メディアストリームを出力として生成します。ストリームの混合方法を説明するポリシーを超えるメディアストリームのグループ化はありません。
A mixer is always under the control of a focus, either directly or indirectly. The focus is responsible for interpreting the media policy, and then installing the appropriate rules in the mixer. If the focus is directly controlling a mixer, the mixer can either be co-resident with the focus, or can be controlled through some kind of protocol. If the focus is indirectly controlling a mixer, it delegates the mixing to the participants, each of which has its own mixer. This is described in Section 6.4.
ミキサーは常に直接的または間接的にフォーカスの制御下にあります。焦点は、メディアポリシーを解釈し、ミキサーに適切なルールをインストールすることです。フォーカスがミキサーを直接制御している場合、ミキサーはフォーカスと共存することも、何らかのプロトコルを介して制御することもできます。フォーカスがミキサーを間接的に制御している場合、ミキシングは参加者に委任され、参加者にはそれぞれ独自のミキサーがあります。これについては、セクション6.4で説明します。
The focus can provide a conference notification service. In this role, it acts as a notifier, as defined in RFC 3265 [4]. It accepts subscriptions from clients for the conference URI, and generates notifications to them as the state of the conference changes.
フォーカスは、会議通知サービスを提供できます。この役割では、RFC 3265 [4]で定義されているように、通知機能として機能します。会議URIのクライアントからのサブスクリプションを受け入れ、会議の状態が変化すると、クライアントへの通知を生成します。
The state of the conference includes the participants connected to the focus, and also information about the dialogs associated with them. As new participants join, this state changes, and is reported through the notification service. Similarly, when someone leaves, this state also changes, allowing subscribers to learn about this fact.
会議の状態には、フォーカスに接続されている参加者と、それらに関連付けられているダイアログに関する情報も含まれます。新しい参加者が加わると、この状態が変化し、通知サービスを通じて報告されます。同様に、誰かが去ると、この状態も変化し、加入者はこの事実を知ることができます。
If a participant is anonymous, the conference notification service will either withhold the identity of a new participant from other conference participants, or will neglect to inform other conference participants about the presence of the anonymous participant. The choice of approach depends on the level of anonymity provided to the anonymous participant.
参加者が匿名の場合、会議通知サービスは、他の会議参加者からの新しい参加者のIDを保留するか、匿名参加者の存在について他の会議参加者に通知することを無視します。アプローチの選択は、匿名の参加者に提供される匿名性のレベルに依存します。
A participant in a conference is any SIP user agent that has a dialog with the focus. This SIP user agent can be a PC application, a SIP hardphone, or a PSTN gateway. It can also be another focus. A conference that has a participant that is the focus of another conference is called a simplex cascaded conference. They can also be used to provide scalable conferences where there are regional sub-conferences, each of which is connected to the main conference.
会議の参加者は、フォーカスのあるダイアログを持つSIPユーザーエージェントです。このSIPユーザーエージェントは、PCアプリケーション、SIPハードフォン、またはPSTNゲートウェイです。それはまた別の焦点となります。別の会議の焦点である参加者がいる会議は、シンプレックスカスケード会議と呼ばれます。また、地域のサブ会議があり、それぞれがメイン会議に接続されているスケーラブルな会議を提供するためにも使用できます。
The conference policy contains the rules that guide the operation of the focus. The rules can be simple, such as an access list that defines the set of allowed participants in a conference. The rules can also be incredibly complex, specifying time-of-day-based rules on participation, conditional on the presence of other participants. It is important to understand that there is no restriction on the type of rules that can be encapsulated in a conference policy.
会議ポリシーには、フォーカスの操作をガイドするルールが含まれています。ルールは、会議の許可された参加者のセットを定義するアクセスリストなど、単純なものにすることができます。ルールは、他の参加者の存在を条件として、参加に関する時刻ベースのルールを指定して、非常に複雑になる場合もあります。会議ポリシーにカプセル化できるルールのタイプに制限がないことを理解することが重要です。
The conference policy can be manipulated using web applications or voice applications. It can also be manipulated with non-SIP-specific standard or proprietary protocols.
会議ポリシーは、Webアプリケーションまたは音声アプリケーションを使用して操作できます。また、SIP固有ではない標準または独自のプロトコルで操作することもできます。
There are a large number of ways in which users can interact with a conference. They can join, leave, set policies, approve members, and so on. This section is meant as an overview of the major conferencing operations, summarizing how they operate. More detailed examples of the SIP mechanisms can be found in [7].
ユーザーが会議と対話する方法は多数あります。参加、退会、ポリシーの設定、メンバーの承認などを行うことができます。このセクションは、主要な会議操作の概要を示し、それらの操作方法を要約しています。 SIPメカニズムのより詳細な例は[7]にあります。
As well as providing an overview of the common conferencing operations, each of the subsections in this section of the document provides a description of the SIP mechanism for supporting the operation. Non-SIP mechanisms are also possible, but not discussed here.
一般的な会議操作の概要を提供するだけでなく、ドキュメントのこのセクションの各サブセクションでは、操作をサポートするためのSIPメカニズムについて説明します。 SIP以外のメカニズムも可能ですが、ここでは説明しません。
There are many ways in which a conference can be created. The creation of a conference actually constructs several elements all at the same time. It results in the creation of a focus and a conference policy. It also results in the construction of a conference URI, which uniquely identifies the focus. Since the conference URI needs to be unique, the element that creates conferences is responsible for guaranteeing that uniqueness. This can be accomplished deterministically (by keeping records of conference URIs, or by generating URIs algorithmically), or probabilistically, (by creating a random URI with sufficiently low probabilities of collision).
会議を作成する方法はたくさんあります。会議の作成は、実際には同時にいくつかの要素を構成します。その結果、焦点と会議ポリシーが作成されます。また、フォーカスを一意に識別する会議URIが構築されます。会議URIは一意である必要があるため、会議を作成する要素はその一意性を保証する責任があります。これは、確定的に（会議URIの記録を保持するか、URIをアルゴリズムで生成することにより）、または確率的に（衝突の確率が十分に低いランダムURIを作成することにより）達成できます。
When conference policy is created, it is established with default rules that are implementation-dependent. If the creator of the conference wishes to change those rules, they would do so using a non-SIP mechanism.
会議ポリシーが作成されると、実装に依存するデフォルトのルールで確立されます。会議の作成者がこれらのルールを変更したい場合、非SIPメカニズムを使用して変更します。
SIP can be used to create conferences hosted in a central server by sending an INVITE to a conferencing application that would automatically create a new conference and then place a user into it.
SIPを使用して、新しい会議を自動的に作成し、そこにユーザーを配置する会議アプリケーションにINVITEを送信することにより、中央サーバーでホストされる会議を作成できます。
Creation of conferences where the focus resides in an endpoint operates differently. There, the endpoint itself creates the conference URI, and hands it out to other endpoints that will be the participants. What differs from case to case is how the endpoint decides to create a conference.
フォーカスがエンドポイントにある会議の作成は、動作が異なります。そこで、エンドポイント自体が会議URIを作成し、参加者になる他のエンドポイントに渡します。ケースごとに異なるのは、エンドポイントが会議の作成を決定する方法です。
One important case is the ad-hoc conference described in Section 6.2. There, an endpoint unilaterally decides to create the conference based on local policy. The dialogs that were connected to the UA are migrated to the endpoint-hosted focus, using a re-INVITE or UPDATE to pass the conference URI to the newly joined participants.
重要なケースの1つは、セクション6.2で説明されているアドホック会議です。そこでは、エンドポイントは一方的にローカルポリシーに基づいて会議を作成することを決定します。 UAに接続されたダイアログは、re-INVITEまたはUPDATEを使用して、エンドポイントがホストするフォーカスに移行され、新しく参加した参加者に会議URIを渡します。
Alternatively, one UA can ask another UA to create an endpoint-hosted conference. This is accomplished with the SIP Join header [10]. The UA that receives the Join header in an invitation may need to create a new conference URI (a new one is not needed if the dialog that is being joined is already part of a conference). The conference URI is then handed to the recently joined participants through a re-INVITE or UPDATE.
または、あるUAが別のUAにエンドポイントがホストする会議の作成を依頼することもできます。これは、SIP Joinヘッダー[10]で実現されます。招待状でJoinヘッダーを受信するUAは、新しい会議URIを作成する必要がある場合があります（参加するダイアログが既に会議の一部である場合、新しいURIは必要ありません）。会議URIは、re-INVITEまたはUPDATEを介して、最近参加した参加者に渡されます。
There are many mechanisms for adding participants to a conference. In all cases, participant additions can be first party (a user adds themself) or third party (a user adds another user).
参加者を会議に追加するメカニズムは多数あります。すべての場合において、参加者の追加は、ファーストパーティ（ユーザーが自分自身を追加）またはサードパーティ（ユーザーが別のユーザーを追加）のいずれかになります。
First person additions using SIP are trivially accomplished with a standard INVITE. A participant can send an INVITE request to the conference URI, and if the conference policy allows them to join, they are added to the conference.
SIPを使用した一人称追加は、標準のINVITEで簡単に実行できます。参加者はINVITE要求を会議URIに送信できます。会議ポリシーで参加を許可されている場合、参加者は会議に追加されます。
If a UA does not know the conference URI, but has learned about a dialog which is connected to a conference (by using the dialog event package, for example [11]), the UA can join the conference by using the Join header to join the dialog.
UAが会議URIを認識していないが、会議に接続されているダイアログについて（ダイアログイベントパッケージを使用して[11]など）学習した場合、UAは、Joinヘッダーを使用して会議に参加し、参加できます。ダイアログ。
Third party additions with SIP are done using REFER [12]. The client can send a REFER request to the participant, asking them to send an INVITE request to the conference URI. Additionally, the client can send a REFER request to the focus, asking it to send an INVITE to the participant. The latter technique has the benefit of allowing a client to add a conference-unaware participant that does not support the REFER method.
SIPによるサードパーティの追加は、REFERを使用して行われます[12]。クライアントはREFER要求を参加者に送信し、会議URIにINVITE要求を送信するように依頼できます。さらに、クライアントは、REFER要求をフォーカスに送信して、参加者にINVITEを送信するように要求できます。後者の手法には、REFERメソッドをサポートしない会議に対応していない参加者をクライアントが追加できるという利点があります。
As with additions, there are several mechanisms for departures. Removals can also be first person or third person.
追加と同様に、離脱にはいくつかのメカニズムがあります。削除は、一人称または三人称でも可能です。
First person departures are trivially accomplished by sending a BYE request to the focus. This terminates the dialog with the focus and removes the participant from the conference. The focus can also remove a participant from the conference by sending it a BYE. In either case, the focus interacts with the mixer to make sure that the departed participant ceases receiving conference media, and that media from that participant are no longer mixed into the conference.
最初の人の出発は、BYEリクエストをフォーカスに送信することで簡単に完了します。これにより、フォーカスのあるダイアログが終了し、参加者が会議から削除されます。フォーカスは、BYEを送信することにより、会議から参加者を削除することもできます。どちらの場合も、フォーカスはミキサーと対話して、離れた参加者が会議メディアの受信を停止し、その参加者からのメディアが会議に混合されないようにします。
Third person departures can also be done using SIP, through the REFER method.
サードパーソンの出発は、REFERメソッドを通じてSIPを使用して行うこともできます。
Conferences can be destroyed in several ways. Generally, whether those means are applicable for any particular conference is a component of the conference policy.
会議はいくつかの方法で破棄できます。一般に、それらの手段が特定の会議に適用できるかどうかは、会議ポリシーのコンポーネントです。
When a conference is destroyed, the conference policy associated with it is destroyed. Any attempts to read or write the policy results in a protocol error. Furthermore, the conference URI becomes invalid. Any attempts to send an INVITE to it, or SUBSCRIBE to it, would result in a SIP error response.
会議が破棄されると、それに関連付けられている会議ポリシーが破棄されます。ポリシーを読み書きしようとすると、プロトコルエラーが発生します。さらに、会議URIは無効になります。 INVITEを送信しようとしたり、SUBSCRIBEを送信しようとすると、SIPエラー応答が発生します。
Typically, if a conference is destroyed while there are still participants, the focus would send a BYE to those participants before actually destroying the conference. Similarly, if there were any users subscribed to the conference notification service, those subscriptions would be terminated by the server before the actual destruction.
通常、参加者がいる間に会議が破棄された場合、フォーカスは実際に会議を破棄する前にBYEをそれらの参加者に送信します。同様に、会議通知サービスにサブスクライブしているユーザーがいる場合、それらのサブスクリプションは実際の破棄の前にサーバーによって終了されます。
There is no explicit means in SIP to destroy a conference. However, a conference may be destroyed as a by-product of a user leaving the conference, which can be done with BYE. In particular, if the conference policy states that the conference is destroyed once the last user or a specific user leaves, when that user does leave (using a SIP BYE request), the conference is destroyed.
SIPには、会議を破棄する明示的な手段はありません。ただし、会議は、BYEを使用して行うことができる、会議を終了するユーザーの副産物として破棄される場合があります。特に、最後のユーザーまたは特定のユーザーが退席すると会議が破棄されると会議ポリシーに記載されている場合、そのユーザーが退出すると（SIP BYE要求を使用して）、会議は破棄されます。
A participant in a conference will frequently wish to know the set of other users in the conference. This information can be obtained in many ways.
会議の参加者は、会議の他のユーザーのセットを知りたいことがよくあります。この情報は、さまざまな方法で取得できます。
The conference notification service allows a conference-aware participant to subscribe to it, and receive notifications that contain the list of participants. When a new participant joins or leaves, subscribers are notified. The conference notification service also allows a user to do a "fetch" [4] to obtain the current listing.
会議通知サービスを使用すると、会議対応の参加者はそれをサブスクライブし、参加者のリストを含む通知を受信できます。新しい参加者が参加または離脱すると、加入者に通知されます。会議通知サービスでは、ユーザーが「取得」[4]して現在のリストを取得することもできます。
Each conference is composed of a particular set of media that the focus is managing. For example, a conference might contain a video stream and an audio stream. The set of media streams that constitute the conference can be changed by participants. When the set of media in the conference change, the focus will need to generate a re-INVITE to each participant in order to add or remove the media stream to each participant. When a media stream is being added, a participant can reject the offered media stream, in which case it will not receive or contribute to that stream. Rejection of a stream by a participant does not imply that the stream is no longer part of the conference, only that the participant is not involved in it.
各会議は、フォーカスが管理しているメディアの特定のセットで構成されています。たとえば、会議にはビデオストリームとオーディオストリームが含まれる場合があります。会議を構成するメディアストリームのセットは、参加者が変更できます。会議のメディアセットが変更された場合、各参加者へのメディアストリームを追加または削除するために、フォーカスは各参加者にre-INVITEを生成する必要があります。メディアストリームが追加されると、参加者は提供されたメディアストリームを拒否できます。その場合、そのストリームを受信したり、そのストリームに投稿したりすることはできません。参加者によるストリームの拒否は、ストリームが会議の一部ではなくなったことを意味するのではなく、参加者が参加していないことを意味します。
A SIP re-INVITE can be used by a participant to add or remove a media stream. This is accomplished using the standard offer/answer techniques for adding media streams to a session [13]. This will trigger the focus to generate its own re-INVITEs.
参加者はSIP re-INVITEを使用して、メディアストリームを追加または削除できます。これは、メディアストリームをセッションに追加するための標準的なオファー/アンサーテクニックを使用して達成されます[13]。これにより、フォーカスがトリガーされ、独自のre-INVITEが生成されます。
Conference announcements and recordings play a key role in many real conferencing systems. Examples of such features include:
会議のアナウンスと録音は、多くの実際の会議システムで重要な役割を果たします。そのような機能の例は次のとおりです。
o Asking a user to state their name before joining the conference, in order to support a roll call
o 点呼をサポートするために、会議に参加する前にユーザーに自分の名前を述べるように依頼する
o Allowing a user to request a roll call, so they can hear who else is in the conference
o 他のユーザーが会議に参加していることを聞くことができるように、ユーザーが点呼を要求できるようにする
o Allowing a user to press some keys on their keypad to record the conference
o ユーザーがキーパッドのキーを押して会議を録音できるようにする
o Allowing a user to press some keys on their keypad to be connected with a human operator
o ユーザーがキーパッドのいくつかのキーを押して、人間のオペレーターと接続できるようにする
o Allowing a user to press some keys on their keypad to mute or unmute their line
o ユーザーがキーパッドのいくつかのキーを押して、回線をミュートまたはミュート解除できるようにする
User 1
+-----------+
| |
| |
|Participant|
| 1 |
| |
+-----------+
|SIP
|Dialog
Conference |1
Policy +---|--------+
User 2 Server | | | Application
+-----------+ +-----------+ | non-SIP *************
| | | | |-------- * *
| | | | | * *
|Participant|-----------| Focus |------------*Participant*
| 2 | SIP | | | SIP * 4 *
| | Dialog | |--+ Dialog * *
+-----------+ 2 +-----------+ 4 *************
|
|
|SIP
|Dialog
|3
|
+-----------+
| |
| |
|Participant|
| 3 |
| |
+-----------+
User 3
Figure 3
図3
In this framework, these capabilities are modeled as an application that acts as a participant in the conference. This is shown pictorially in Figure 3. The conference has four participants. Three of these participants are end users, and the fourth is the announcement application.
このフレームワークでは、これらの機能は、会議の参加者として機能するアプリケーションとしてモデル化されています。これを図3に図で示します。会議には4人の参加者がいます。これらの参加者のうち3人はエンドユーザーで、4人目はアナウンスアプリケーションです。
If the announcement application wishes to play an announcement to all the conference members (for example, to announce a join), it merely sends media to the mixer as would any other participant. The announcement is mixed in with the conversation and played to the participants.
アナウンスアプリケーションがすべての会議メンバーにアナウンスを再生する（たとえば、参加をアナウンスする）場合は、他の参加者と同様に、メディアをミキサーに送信するだけです。アナウンスは会話に組み込まれ、参加者に再生されます。
Similarly, the announcement application can play an announcement to a specific user by configuring the conference policy so that the media it generates is only heard by the target user. The application then generates the desired announcement, and it will be heard only by the selected recipient.
同様に、アナウンスアプリケーションは、生成するメディアがターゲットユーザーのみに聞こえるように会議ポリシーを構成することにより、特定のユーザーへのアナウンスを再生できます。次に、アプリケーションは目的のアナウンスを生成し、選択された受信者だけがそれを聞くことができます。
The announcement application can also receive input from a specific user through the conference. To do this, it can use the application interaction framework [6]. This allows it to collect user input, possibly through keypad stimulus, and to take actions.
アナウンスアプリケーションは、会議を通じて特定のユーザーからの入力を受け取ることもできます。これを行うには、アプリケーション対話フレームワークを使用できます[6]。これにより、おそらくキーパッド刺激を介してユーザー入力を収集し、アクションを実行できます。
In this section, we present several physical instantiations of these components, to show how these basic functions can be combined to solve a variety of problems.
このセクションでは、これらのコンポーネントの物理的なインスタンスをいくつか示し、これらの基本的な機能を組み合わせてさまざまな問題を解決する方法を示します。
In the most simplistic realization of this framework, there is a single physical server in the network, which implements the focus, the conference policy server, and the mixers. This is the classic "one box" solution, shown in Figure 4.
このフレームワークの最も単純な実現では、ネットワークに単一の物理サーバーがあり、フォーカス、会議ポリシーサーバー、およびミキサーを実装します。これは、図4に示す、古典的な「1つのボックス」ソリューションです。
Conference Server
...................................
. .
. +------------+ .
. | Conference | .
. |Notification| .
. | Server | .
. +------------+ .
. +----------+ .
. |Conference| +-----+ .
. | Policy | +-------+ +-----+| .
. | Server | | Focus | |Mixer|+ .
. +----------+ +-------+ +-----+ .
................//.\.....***.......
// \ *** *
// *** * RTP
SIP // *** \ *
// *** \SIP *
// *** RTP \ *
/ ** \ *
+-----------+ +-----------+
|Participant| |Participant|
+-----------+ +-----------+
Figure 4
図4
Another important model is that of a locally-mixed ad-hoc conference. In this scenario, two users (A and B) are in a regular point-to-point call. One of the participants (A) decides to conference-in a third participant, C. To do this, A begins acting as a focus. Its existing dialog with B becomes the first dialog attached to the focus. A would re-INVITE B on that dialog, changing its Contact URI to a new value that identifies the focus. In essence, A "mutates" from a single-user UA to a focus plus a single user UA, and in the process of such a mutation, its URI changes. Then, the focus makes an outbound INVITE to C. When C accepts, it mixes the media from B and C together, redistributing the results. The mixed media is also played locally. Figure 5 shows a diagram of this transition.
もう1つの重要なモデルは、ローカルに混在するアドホック会議のモデルです。このシナリオでは、2人のユーザー（AとB）が通常のポイントツーポイント通話をしています。参加者の1人（A）が、3人目の参加者Cで会議に参加することを決定します。これを行うために、Aがフォーカスとして機能し始めます。 Bが付いた既存のダイアログが、フォーカスに関連付けられた最初のダイアログになります。 AはそのダイアログでBを再度招待し、Contact URIをフォーカスを識別する新しい値に変更します。本質的に、AはシングルユーザーUAからフォーカスとシングルユーザーUAに「変化」し、そのような変化の過程で、そのURIが変化します。次に、フォーカスはCへの発信INVITEを作成します。Cが受け入れると、BとCからのメディアが混合され、結果が再配布されます。ミクストメディアもローカルで再生されます。図5は、この遷移の図を示しています。
B B
+------+ +------+
| | | |
| UA | | UA |
| | | |
+------+ +------+
| . | .
| . | .
| . | .
| . Transition | .
| . ------------> | .
SIP| .RTP SIP| .RTP
| . | .
| . | .
| . | .
| . | .
| . +----------+
+------+ | +------+ | SIP +------+
| | | |Focus | |----------| |
| UA | | |C.Pol.| | | UA |
| | | |Mixers| |..........| |
+------+ | | | | RTP +------+
| +------+ |
A | + | C
| + <..|.......
| + | .
| +------+ | .
| |Parti-| | .
| |cipant| | .
| | | | .
| +------+ | .
+----------+ .
A .
.
Internal Interface
内部インターフェース
Figure 5
図5
It is important to note that the external interfaces in this model, between A and B, and between B and C, are exactly the same to those that would be used in a centralized server model. User A could also implement a conference policy and a conference notification service, allowing the participants to have access to them if they so desired. Just because the focus is co-resident with a participant does not mean any aspect of the behaviors and external interfaces will change.
このモデルのAとBの間、およびBとCの間の外部インターフェイスは、集中型サーバーモデルで使用されるものとまったく同じであることに注意することが重要です。ユーザーAは、会議ポリシーと会議通知サービスを実装して、必要に応じて参加者がアクセスできるようにすることもできます。フォーカスが参加者と共存しているからといって、動作のいかなる側面も意味せず、外部インターフェースが変更されます。
+------------+ +------------+
| App Server| SIP |Conf. Cmpnt.|
| |-------------| |
| Focus | non-SIP | Focus |
| C.Pol |-------------| C.Pol |
| | | Mixers |
|Notification| | |
| | | |
+------------+ +------------+
| \ .. .
| \\ RTP... .
| \\ .. .
| SIP \\ ... .
SIP | \\ ... .RTP
| ..\ .
| ... \\ .
| ... \\ .
| .. \\ .
| ... \\ .
| .. \ .
+-----------+ +-----------+
|Participant| |Participant|
+-----------+ +-----------+
Figure 6
図6
In this model, shown in Figure 6, each conference involves two centralized servers. One of these servers, referred to as the "application server" owns and manages the membership and media policies, and maintains a dialog with each participant. As a result, it represents the focus seen by all participants in a conference. However, this server doesn't provide any media support. To perform the actual media mixing function, it makes use of a second server, called the "mixing server". This server includes a focus, and implements a conference policy, but has no conference notification service. Its conference policy tells it to accept all invitations from the top-level focus. The focus in the application server uses third party call control to connect the media streams of each user to the mixing server, as needed. If the focus in the application server receives a conference policy control command from a client, it delegates that to the media server by making the same media policy control command to it.
このモデルでは、図6に示すように、各会議に2つの集中サーバーが含まれます。 「アプリケーションサーバー」と呼ばれるこれらのサーバーの1つは、メンバーシップとメディアポリシーを所有および管理し、各参加者とのダイアログを維持します。結果として、それは会議のすべての参加者が見る焦点を表しています。ただし、このサーバーはメディアサポートを提供しません。実際のメディアミキシング機能を実行するには、「ミキシングサーバー」と呼ばれる2番目のサーバーを使用します。このサーバーはフォーカスを含み、会議ポリシーを実装しますが、会議通知サービスはありません。その会議の方針は、トップレベルの焦点からのすべての招待を受け入れるようにそれに指示します。アプリケーションサーバーでは、必要に応じて、サードパーティの通話制御を使用して、各ユーザーのメディアストリームをミキシングサーバーに接続します。アプリケーションサーバーのフォーカスがクライアントから会議ポリシー制御コマンドを受け取ると、同じメディアポリシー制御コマンドをクライアントに送信することにより、それをメディアサーバーに委任します。
This model allows for the mixing server to be used as a resource for a variety of different conferencing applications. This is because it is unaware of conference policy; it is merely a "slave" to the top-level server, doing whatever it asks.
このモデルでは、ミキシングサーバーをさまざまな会議アプリケーションのリソースとして使用できます。これは、会議のポリシーを認識していないためです。これは、トップレベルサーバーへの "スレーブ"であり、要求に応じて実行します。
In a distributed mixed conference, there is still a centralized server that implements the focus, conference policy server, and media policy server. However, there are no centralized mixers. Rather, there are mixers in each endpoint, along with a conference policy server. The focus distributes the media by using third party call control [14] to move a media stream between each participant and each other participant. As a result, if there are N participants in the conference, there will be a single dialog between each participant and the focus, but the session description associated with that dialog will be constructed to allow media to be distributed amongst the participants. This is shown in Figure 7.
分散混合会議では、フォーカス、会議ポリシーサーバー、およびメディアポリシーサーバーを実装する集中型サーバーが引き続き存在します。ただし、集中型ミキサーはありません。むしろ、会議ポリシーサーバーとともに、各エンドポイントにミキサーがあります。フォーカスは、サードパーティコールコントロール[14]を使用してメディアを配信し、各参加者と他の各参加者の間でメディアストリームを移動します。その結果、会議にN人の参加者がいる場合、各参加者とフォーカスの間に1つのダイアログがありますが、そのダイアログに関連付けられたセッションの説明は、参加者間でメディアを配布できるように構成されます。これを図7に示します。
+---------+
|Partcpnt |
media | | media
...............| |..................
. | Mixers | .
. |C.Pol.Srv| .
. +---------+ .
. | .
. | .
. | .
. dialog | .
. | .
. | .
. | .
. +---------+ .
. |Cnf.Srvr.| .
. | | .
. | Focus | .
. |C.Pol.Srv| .
. / | | \ .
. / +---------+ \ .
. / \ .
. / \ .
. / dialog \ .
. / \ .
. /dialog \ .
. / \ .
. / \ .
. / \ .
. .
+---------+ +---------+
|Partcpnt | |Partcpnt |
| | | |
| | ......................... | |
| Mixers | | Mixers |
|C.Pol.Srv| media |C.Pol.Srv|
+---------+ +---------+
Figure 7
図7
There are several ways in which the media can be distributed to each participant for mixing. In a multi-unicast model, each participant sends a copy of its media to each other participant. In this case, the session description manages N-1 media streams. In a multicast model, each participant joins a common multicast group, and each participant sends a single copy of its media stream to that group. The underlying multicast infrastructure then distributes the media, so that each participant gets a copy. In a single-source multicast model (SSM), each participant sends its media stream to a central point, using unicast. The central point then redistributes the media to all participants using multicast. The focus is responsible for selecting the modality of media distribution, and for handling any hybrids that would be necessitated from clients with mixed capabilities.
メディアを各参加者に配布してミキシングする方法はいくつかあります。マルチユニキャストモデルでは、各参加者がメディアのコピーを他の各参加者に送信します。この場合、セッション記述はN-1個のメディアストリームを管理します。マルチキャストモデルでは、各参加者が共通のマルチキャストグループに参加し、各参加者がメディアストリームの単一のコピーをそのグループに送信します。次に、基盤となるマルチキャストインフラストラクチャがメディアを配布し、各参加者がコピーを取得できるようにします。単一ソースマルチキャストモデル（SSM）では、各参加者がユニキャストを使用してメディアストリームを中央ポイントに送信します。次に中心点は、マルチキャストを使用してすべての参加者にメディアを再配布します。フォーカスは、メディア配布のモダリティの選択、および混合機能を持つクライアントから必要となるハイブリッドの処理に責任があります。
When a new participant joins or is added, the focus will perform the necessary third party call control to distribute the media from the new participant to all the other participants, and vice versa.
新しい参加者が参加または追加されると、フォーカスは必要なサードパーティコール制御を実行して、新しい参加者から他のすべての参加者に、またはその逆にメディアを配信します。
The central conference server also exposes an interface to the conference policy. Of course, the central conference server cannot implement any of the media operations or policies directly. Rather, it would delegate the implementation to each participant. As an example, if a participant decides to switch the overall conference mode from "voice activated" to "continuous presence", they would communicate with the central conference policy server. The conference policy server, in turn, would communicate with the conference policy servers that are co-resident with each participant, using some non-SIP-specific mechanism, and instruct them to use "continuous presence".
中央会議サーバーは、会議ポリシーへのインターフェイスも公開します。もちろん、中央会議サーバーは、メディア操作やポリシーを直接実装することはできません。むしろ、各参加者に実装を委任します。例として、参加者が会議全体のモードを「音声起動」から「継続的プレゼンス」に切り替えることを決定した場合、参加者は中央会議ポリシーサーバーと通信します。次に、会議ポリシーサーバーは、SIP固有でないメカニズムを使用して、各参加者と共存する会議ポリシーサーバーと通信し、「継続的プレゼンス」を使用するように指示します。
This model requires additional functionality in user agents, which may or may not be present. The participants, therefore, must be able to advertise this capability to the focus.
このモデルでは、ユーザーエージェントに追加の機能が必要ですが、存在しない場合もあります。したがって、参加者はこの機能をフォーカスして宣伝できる必要があります。
In very large conferences, it may not be possible to have a single mixer that can handle all of the media. A solution to this is to use cascaded mixers. In this architecture, there is a centralized focus, but the mixing function is implemented by a multiplicity of mixers, scattered throughout the network. Each participant is connected to one, and only one of the mixers. The focus uses some kind of control protocol to connect the mixers together, so that all of the participants can hear each other.
非常に大規模な会議では、すべてのメディアを処理できる単一のミキサーを使用できない場合があります。これに対する解決策は、カスケードミキサーを使用することです。このアーキテクチャでは、集中化された焦点がありますが、ミキシング機能は、ネットワーク全体に散在する多数のミキサーによって実装されます。各参加者は1つに接続され、ミキサーの1つだけに接続されます。フォーカスでは、ある種の制御プロトコルを使用してミキサーを接続し、参加者全員が互いに聞こえるようにします。
This architecture is shown in Figure 8.
このアーキテクチャを図8に示します。
+---------+
+-----------------------| |------------------------+
| ++++++++++++++++++++| |++++++++++++++++++ |
| + +------| Focus |---------+ + |
| + | | | | + |
| + | +-| |--+ | + |
| + | | +---------+ | | + |
| + | | + | | + |
| + | | + | | + |
| + | | + | | + |
| + | | +---------+ | | + |
| + | | | | | | + |
| + | | | Mixer 2 | | | + |
| + | | | | | | + |
| + | | +---------+ | | + |
| + | |... . .... | | + |
| + .|....| . .|.... | + |
| + ...... | | . | ..|... + |
| + ... | | . | | ....+ |
| +---------+ | | +---------+ | | +---------+ |
| | | | | | | | | | | |
| | Mixer 2 | | | | Mixer 3 | | | | Mixer 4 | |
| | | | | | | | | | | |
| +---------+ | | +---------+ | | +---------+ |
| . . | | . . | | . . |
| . . | | .. . | | .. . |
| . . | | . . | | . . |
+---------+ . | +---------+ . | +---------+ . |
| Prtcpnt | . | | Prtcpnt | . | | Prtcpnt | . |
| 1 | . | | 3 | . | | 5 | . |
+---------+ . | +---------+ . | +---------+ . |
. | . | . |
+---------+ +---------+ +---------+
| Prtcpnt | | Prtcpnt | | Prtcpnt |
| 2 | | 4 | | 6 |
+---------+ +---------+ +---------+
------- SIP Dialog
....... Media Flow
+++++++ Control Protocol
Figure 8
図8
Conferences frequently require security features in order to properly operate. The conference policy may dictate that only certain participants can join, or that certain participants can create new policies. Generally speaking, conference applications are very concerned about authorization decisions. Having mechanisms for establishing and enforcing such authorization rules is a central concept throughout this document.
会議が適切に動作するためには、セキュリティ機能が必要になることがよくあります。会議のポリシーにより、特定の参加者のみが参加できる、または特定の参加者が新しいポリシーを作成できることが指示される場合があります。一般的に言えば、会議アプリケーションは承認の決定について非常に懸念しています。このような承認ルールを確立して適用するメカニズムを持つことは、このドキュメント全体の中心的な概念です。
Of course, authorization rules require authentication. Normal SIP authentication mechanisms should suffice for the conference authorization mechanisms described here.
もちろん、認可ルールには認証が必要です。ここで説明する会議承認メカニズムには、通常のSIP認証メカニズムで十分です。
Privacy is an important aspect of conferencing. Users may wish to join a conference without anyone knowing that they have joined, in order to silently listen in. In other applications, a participant may wish to hide only their identity from other participants, but otherwise let them know of their presence. These functions need to be provided by the conferencing system.
プライバシーは会議の重要な側面です。ユーザーは、参加していることをだれにも知らずに会議に参加したい場合があります。他のアプリケーションでは、参加者は自分のIDのみを他の参加者から隠し、それ以外の場合は自分の存在を知らせたい場合があります。これらの機能は、会議システムによって提供される必要があります。
This document is the result of discussions amongst the conferencing design team. The members of this team include:
このドキュメントは、会議の設計チーム間の議論の結果です。このチームのメンバーは次のとおりです。
Alan Johnston Brian Rosen Rohan Mahy Henning Schulzrinne Orit Levin Roni Even Tom Taylor Petri Koskelainen Nermeen Ismail Andy Zmolek Joerg Ott Dan Petrie
アランジョンストンブライアンローゼンローハンマヒヘニングシュルズリンネオリットレヴィンロニトムテイラーペトリコスケライネンネルミーンイスマイルアンディズモレクジョルグオットダンペトリー
The authors would like to thank Mary Barnes, Chris Boulton and Rohan Mahy for their comments. Thanks to Allison Mankin for her comments and support of this work.
著者は、コメントしてくれたMary Barnes、Chris Boulton、Rohan Mahyに感謝します。この作業に対するコメントとサポートを提供してくれたAllison Mankinに感謝します。
[1] 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.
[1] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：Session Initiation Protocol」、RFC 3261 、2002年6月。
[2] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[2] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：A Transport Protocol for Real-Time Applications」、STD 64、RFC 3550、2003年7月。
[3] Levin, O. and R. Even, "High-Level Requirements for Tightly Coupled SIP Conferencing", RFC 4245, November 2005.
[3] Levin、O。およびR. Even、「密結合SIP会議の高レベル要件」、RFC 4245、2005年11月。
[4] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[4] Roach、A。、「Session Initiation Protocol（SIP）-Specific Event Notification」、RFC 3265、2002年6月。
[5] Campbell, B., "The Message Session Relay Protocol", Work In Progress, October 2004.
[5] キャンベルB.、「メッセージセッションリレープロトコル」、作業中、2004年10月。
[6] Rosenberg, J., "A Framework for Application Interaction in the Session Initiation Protocol (SIP)", Work In Progress, February 2005.
[6] Rosenberg、J。、「Session Initiation Protocol（SIP）におけるアプリケーション相互作用のフレームワーク」、進行中の作業、2005年2月。
[7] Johnston, A. and O. Levin, "Session Initiation Protocol (SIP) Call Control - Conferencing for User Agents", Work in Progress, February 2005.
[7] Johnston、A.およびO. Levin、「Session Initiation Protocol（SIP）Call Control-Conferencing for User Agents」、Work in Progress、2005年2月。
[8] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[8] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、STD 66、RFC 3986、2005年1月。
[9] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004.
[9] Rosenberg、J.、Schulzrinne、H。、およびP. Kyzivat、「Initiating User Agent Capabilities in the Session Initiation Protocol（SIP）」、RFC 3840、2004年8月。
[10] Mahy, R. and D. Petrie, "The Session Initiation Protocol (SIP) "Join" Header", RFC 3911, October 2004.
[10] Mahy、R。およびD. Petrie、「Session Initiation Protocol（SIP） "Join" Header」、RFC 3911、2004年10月。
[11] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol (SIP)", RFC 4235, November 2005.
[11] Rosenberg、J.、Schulzrinne、H。、およびR. Mahy、「セッション開始プロトコル（SIP）のINVITEで開始されるダイアログイベントパッケージ」、RFC 4235、2005年11月。
[12] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[12] Sparks、R。、「Session Initiation Protocol（SIP）Refer Method」、RFC 3515、2003年4月。
[13] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[13] Rosenberg、J。およびH. Schulzrinne、「セッション記述プロトコル（SDP）を備えたオファー/アンサーモデル」、RFC 3264、2002年6月。
[14] 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.
[14] Rosenberg、J.、Peterson、J.、Schulzrinne、H。、およびG. Camarillo、「Session Initiation Protocol（SIP）におけるサードパーティコール制御（3pcc）のベストプラクティス」、BCP 85、RFC 3725、2004年4月。
[15] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002.
[15] Rosenberg、J。、「セッション開始プロトコル（SIP）UPDATEメソッド」、RFC 3311、2002年10月。
Author's Address
著者のアドレス
Jonathan Rosenberg Cisco Systems 600 Lanidex Plaza Parsippany, NJ 07054 US
Jonathan Rosenberg Cisco Systems 600 Lanidex Plaza Parsippany、NJ 07054 US
Phone: +1 973 952-5000
EMail: jdrosen@cisco.com
URI: http://www.jdrosen.net
Full Copyright Statement
Copyright (C) The Internet Society (2006).
Copyright（C）The Internet Society（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントは、BCP 78に含まれる権利、ライセンス、および制限の対象であり、そこに記載されている場合を除き、著者はすべての権利を保持します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」で提供され、寄稿者、彼/彼女の代理人、または組織（ある場合）、インターネットエンジニアリングおよびインターネットエンジニアリングタスクフォースは、すべての保証を明示的または明示的に後援します。ここに含まれる情報の使用により、商品性または特定の目的への適合性に関するいかなる権利または黙示の保証も侵害されないという保証を含みますが、これに限定されるものではありません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、このドキュメントに記載されているテクノロジーの実装または使用に関連すると主張される可能性がある知的財産権またはその他の権利の有効性または範囲、またはそのような権利に基づくライセンスが適用されるかどうかに関係なく、いかなる立場も取りません。利用できる;また、そのような権利を特定するために独立した取り組みを行ったことを表すものでもありません。 RFC文書の権利に関する手順に関する情報は、BCP 78およびBCP 79にあります。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に対して行われたIPR開示のコピー、および使用可能にされるライセンスの保証、または一般ライセンスを取得する試みの結果、またはこの仕様の実装者またはユーザーがそのような所有権を使用するための許可を取得できるhttp://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、この規格を実装するために必要となる可能性のある技術をカバーする可能性のある著作権、特許、特許出願、またはその他の所有権に注意を向けるよう、関係者に呼びかけます。 IEETのietf-ipr@ietf.orgに情報を送信してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポート活動（IASA）によって提供されます。