RFC4353 日本語訳
4353 A Framework for Conferencing with the Session Initiation Protocol(SIP). J. Rosenberg. February 2006. (Format: TXT=67405 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Rosenberg Request for Comments: 4353 Cisco Systems Category: Informational February 2006
コメントを求めるワーキンググループJ.ローゼンバーグの要求をネットワークでつないでください: 4353年のシスコシステムズカテゴリ: 情報の2006年2月
A Framework for Conferencing with the
Session Initiation Protocol (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)インターネット協会(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.
Session Initiationプロトコル(SIP)はユーザエージェントの間のメディアセッションの開始、変更、および終了をサポートします。 これらのセッションはSIP対話によって管理されます。(対話は1組のユーザエージェントの間の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
1. 序論…2 2. 用語…3 3. 会議アーキテクチャの概要…6 3.1. URIの用法…9 4. Elementsの機能…10 4.1. 集中してください…10 4.2. コンファレンス方針サーバ…11 4.3. ミキサー…11 4.4. コンファレンス通知サービス…12 4.5. 関係者…13 4.6. コンファレンス方針…13 5. 一般的な操作…13 5.1. コンファレンスを作成します…13 5.2. 関係者を加えます…14
Rosenberg Informational [Page 1] RFC 4353 Conferencing Framework with SIP February 2006
一口2006年2月があるローゼンバーグ情報[1ページ]のRFC4353会議フレームワーク
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
5.3. 関係者を外します…15 5.4. コンファレンスを破壊します…15 5.5. 会員資格情報を得ます…16 5.6. メディアを加えて、取り除きます…16 5.7. コンファレンス発表と録音…16 6. 物理的な実現…18 6.1. サーバを集結します…18 6.2. 終点サーバ…19 6.3. メディアサーバコンポーネント…21 6.4. 混合を分配します…22 6.5. ミキサーをどっと落させています…24 7. セキュリティ問題…26 8. 貢献者…26 9. 承認…26 10. 有益な参照…27
1. Introduction
1. 序論
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.
Session Initiationプロトコル(SIP)[1]はユーザエージェントの間のメディアセッションの開始、変更、および終了をサポートします。 これらのセッションはSIP対話によって管理されます。(対話は1組のユーザエージェントの間のSIP関係を表します)。 ユーザエージェントの組の間には、対話があるので、2パーティーのコミュニケーション(電話などの)のためのSIPの用法は明白です。 しかしながら、複数の関係者とのコミュニケーションセッションは、より複雑です。 SIPはマルチパーティコミュニケーションの多くのモデルをサポートできます。 緩く結合した会議と呼ばれたのはマルチキャストメディアグループを利用します。 緩く結合したモデルには、会議の関係者の間には、シグナリング関係が全くありません。 コントロールか会議サーバのどんな主要なポイントもありません。参加は会議(例えば、レアルTime Controlプロトコル(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.
時々密結合会議と呼ばれた別のモデルには、コントロールの主要なポイントがあります。 各関係者はこの主要なポイントに接続します。 それは、さまざまな会議機能を提供して、ことによるとまた、機能を混ぜながら、メディアを実行するかもしれません。 基本的な参加は少しも追加議定書サポートなしで可能ですが、密結合会議はRFC3261によって直接演説されません。
Rosenberg Informational [Page 2] RFC 4353 Conferencing Framework with SIP February 2006
一口2006年2月があるローゼンバーグ情報[2ページ]のRFC4353会議フレームワーク
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の詳細メカニズムについて暗示します。 この仕様の範囲の外にそれらのメカニズムがあります。
2. Terminology
2. 用語
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の詳細メカニズムを実装するかもしれません。
Rosenberg Informational [Page 3] RFC 4353 Conferencing Framework with SIP February 2006
一口2006年2月があるローゼンバーグ情報[3ページ]のRFC4353会議フレームワーク
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.
コンファレンス通知サービス: 会議通知サービスは焦点によって提供された論理関数です。 焦点はnotifier[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]を使用することで輸送されたメディアを含んでいます。 その結果、ここで定義された用語はRFC3550で定義されたミキサー概念のスーパーセットです、それ以来許容、非、-、インスタントメッセージングセッション[5]などのRTPによるベースのメディア。
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.
会議をどっと落させています: それらの焦点を何らかのファッションで相互作用させることによって1セットの会議がリンクされるグループコミュニケーションのためのメカニズム。
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.
シンプレクスはコンファレンスをどっと落させました: 1つの会議の焦点を表すユーザエージェントが別の会議の会議気づかない関係者であるように繋がっている会議のグループ。
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.
コンファレンスサーバ: 会議サーバは最小限で焦点を含む物理的なサーバです。 また、それは会議方針サーバとミキサーを含むかもしれません。
Rosenberg Informational [Page 4] RFC 4353 Conferencing Framework with SIP February 2006
一口2006年2月があるローゼンバーグ情報[4ページ]のRFC4353会議フレームワーク
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.
匿名の関係者: 匿名の関係者は他の関係者にとって会議通知サービスで知られていますが、アイデンティティが差し控えられているものです。
Rosenberg Informational [Page 5] RFC 4353 Conferencing Framework with SIP February 2006
一口2006年2月があるローゼンバーグ情報[5ページ]のRFC4353会議フレームワーク
3. Overview of Conferencing Architecture
3. 会議アーキテクチャの概要
+-----------+
| |
| |
|Participant|
| 4 |
| |
+-----------+
|
|SIP
|Dialog
|4
|
+-----------+ +-----------+ +-----------+
| | | | | |
| | | | | |
|Participant|-----------| Focus |------------|Participant|
| 1 | SIP | | SIP | 3 |
| | Dialog | | Dialog | |
+-----------+ 1 +-----------+ 3 +-----------+
|
|
|SIP
|Dialog
|2
|
+-----------+
| |
| |
|Participant|
| 2 |
| |
+-----------+
+-----------+ | | | | |関係者| | 4 | | | +-----------+ | |一口|対話|4 | +-----------+ +-----------+ +-----------+ | | | | | | | | | | | | |関係者|-----------| 焦点|------------|関係者| | 1 | 一口| | 一口| 3 | | | 対話| | 対話| | +-----------+ 1 +-----------+ 3 +-----------+ | | |一口|対話|2 | +-----------+ | | | | |関係者| | 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個以上のミキサーの使用でします。それはそれぞれ多くの入力メディアストリームを合成します。焦点は、ミキサーの適切な構成を決定するのにメディア方針を使用します。
Rosenberg Informational [Page 6] RFC 4353 Conferencing Framework with SIP February 2006
一口2006年2月があるローゼンバーグ情報[6ページ]のRFC4353会議フレームワーク
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.
会議URIにINVITEを送ることによって、通常、ユーザは会議に参加します。 会議方針として長さが許容するように、焦点で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を使用することで会議に参加して、出て、刺激シグナリングを通して、より高度な特徴を得ることができます。 しかしながら、関係者が機能的なシグナリングプロトコルを使用することで明らかに会議の局面を制御したいなら、関係者は会議意識しているに違いありません。
Rosenberg Informational [Page 7] RFC 4353 Conferencing Framework with SIP February 2006
一口2006年2月があるローゼンバーグ情報[7ページ]のRFC4353会議フレームワーク
.....................................
. .
. .
. .
. .
. .
. .
. .
. +-----------+ //-----\\ .
. | | || || .
non-SIP . | Conference| \\-----// .
+---------------->| Policy | | | .
| . | Server |----> | | .
| . | | |Conference| .
| . +-----------+ | Policy | .
| . | | .
| . | | .
+-----------+ . +-----------+ | | .
| | . | | \ // .
| | . | | \-----/ .
|Participant|<--------->| Focus | | .
| | SIP . | | | .
| | Dialog . | |<-----------+ .
+-----------+ . |...........| .
^ . | Conference| .
| . |Notification .
+------------>| Service | .
Subscription. +-----------+ .
. .
. .
. .
. .
.....................................
..................................... . . . . . . . . . . . . . . . +-----------+ //-----\\ . . | | || || . 非一口。| コンファレンス| \\-----// . +---------------->| 方針| | | . | . | サーバ|、-、-、--、>|、| . | . | | |コンファレンス| . | . +-----------+ | 方針| . | . | | . | . | | . +-----------+ . +-----------+ | | . | | . | | \ // . | | . | | \-----/ . |関係者| <、-、-、-、-、-、-、-、--、>| 焦点| | . | | ちびちび飲んでください。| | | . | | 対話。| | <、-、-、-、-、-、-、-、-、-、--+ . +-----------+ . |...........| . ^ . | コンファレンス| . | . |通知+------------>| サービス| . 購読。 +-----------+ . . . . . . . . . .....................................
Conference
Functions
コンファレンス機能
Figure 2
図2
Rosenberg Informational [Page 8] RFC 4353 Conferencing Framework with SIP February 2006
一口2006年2月があるローゼンバーグ情報[8ページ]のRFC4353会議フレームワーク
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実装に柔軟性を提供します。
3.1. Usage of URIs
3.1. URIの用法
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がユニークであるので、いいえtwo、会議には、同じ会議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は不透明です。 URIを見て、それが焦点を特定するかどうかを確かに知る方法が全くありません、PSTNゲートウェイの上のユーザかインタフェースと対照的に。 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を作成する要素かシステムがこの特性を保証するのに原因となります。
Rosenberg Informational [Page 9] RFC 4353 Conferencing Framework with SIP February 2006
一口2006年2月があるローゼンバーグ情報[9ページ]のRFC4353会議フレームワーク
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は「一口: 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をリンクできます。 また、何らかの非SIPメカニズムから会議URIを得ることができます。
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]は、UAがこの対話における焦点として機能しているのを示すために"isfocus"特徴タグを提供します。 また、訪問される人能力パラメタは、焦点が、会議通知がサービスであるとサポートするのを示すのに使用されます。 候補の支持にまわることによってこれをする、登録、メソッドと訪問者好みにおける関連パッケージは会議URIに関連しているパラメタを特徴とします。
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によって表されるかもしれません。 会議方針がウェブアプリケーションで暴露されるなら、それは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について学習できます。
4. Functions of the Elements
4. Elementsの機能
This section gives a more detailed description of the functions typically implemented in each of the elements.
このセクションはそれぞれの要素で通常実装された機能の、より詳細な記述を与えます。
4.1. Focus
4.1. 焦点
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対話によってそれに接されます。 焦点はそれに接続された対話を維持するのに責任があります。 それは、対話が会議に参加できる1セットの関係者に接されるのを確実にします、会員資格方針で定義されるように。 また、焦点はメディアセッションを操るのにSIPを使用します、各関係者が会議のためのすべてのメディアを得るのを確実にするために。 それをするために、焦点はミキサーを利用します。
Rosenberg Informational [Page 10] RFC 4353 Conferencing Framework with SIP February 2006
一口2006年2月があるローゼンバーグ情報[10ページ]のRFC4353会議フレームワーク
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関係者のためにセッション(例えばビデオを取り外す)のメディアの資産を変えるのが必要であるなら、焦点は、その関係者のために新しい申し出と共に再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アドレスとポートにメディアを送るのを確実にします。 この仕様の範囲の外に焦点がミキサーと対話する手段があります。
4.2. Conference Policy Server
4.2. コンファレンス方針サーバ
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の詳細メカニズムを使用することで会議方針サーバとコミュニケートします。
4.3. Mixers
4.3. ミキサー
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
ミキサーが会議を構成しているメディアの流れを合成して、受取人に分配される1つ以上の出力ストリームを発生させるのに原因となる、(何らかの関係者であるかもしれません。
Rosenberg Informational [Page 11] RFC 4353 Conferencing Framework with SIP February 2006
一口2006年2月があるローゼンバーグ情報[11ページ]のRFC4353会議枠組み
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.
ミキサー) メディアを合併する過程は、メディアタイプに特定であり、焦点によって指示されます、メディア方針で説明された規則の指導の下に。
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で説明されます。
4.4. Conference Notification Service
4.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.
焦点は会議通知サービスを提供できます。 この役割では、それはnotifier RFC3265[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.
関係者が匿名であるなら、会議通知サービスは、他の会議の参加者から新しい関係者のアイデンティティを差し控えるか、または匿名の関係者の存在に関して他の会議の参加者に知らせるのを忘れるでしょう。 アプローチのこの選択は匿名の関係者に提供された匿名のレベル次第です。
Rosenberg Informational [Page 12] RFC 4353 Conferencing Framework with SIP February 2006
一口2006年2月があるローゼンバーグ情報[12ページ]のRFC4353会議枠組み
4.5. Participants
4.5. 関係者
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 hardphone、またはPSTNがゲートウェイであったならそうすることができます。 また、それは別の焦点であるかもしれません。 関係者のためにそれを持っている会議は別の会議の焦点がシンプレクスのどっと落している会議と呼ばれるということです。 また、地方のサブ会議があるところにスケーラブルな会議を提供するのにそれらを使用できます。それはそれぞれ主な会議に関連づけられます。
4.6. Conference Policy
4.6. コンファレンス方針
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.
ウェブアプリケーションか音声アプリケーションを使用することで会議方針を操ることができます。 また、非SIPの詳細規格か固有のプロトコルでそれを操ることができます。
5. Common Operations
5. 一般的な操作
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].
ユーザが会議と対話できる多くの方法があります。 彼らは接合できて、休暇(セット方針)はメンバーなどを承認します。 それらがどう作動するかをまとめて、このセクションは主要な会議操作の概観として意味されます。 [7]でSIPメカニズムの、より詳細な例を見つけることができます。
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メカニズムは、可能ですがも、ここで議論されていません。
5.1. Creating Conferences
5.1. コンファレンスを作成します。
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
会議を創設できる多くの方法があります。 会議の創設はすべて同時に、実際に数個の要素を構成します。 それは焦点と会議方針の創造をもたらします。 また、それは会議URIの工事をもたらします。(唯一、URIは焦点を特定します)。 会議URIが、特有である必要があるので、会議を創設する要素はそのユニークさを保証するのに原因となります。 決定論的にこれを達成できる、(記録をつけます。
Rosenberg Informational [Page 13] RFC 4353 Conferencing Framework with SIP February 2006
一口2006年2月があるローゼンバーグ情報[13ページ]のRFC4353会議枠組み
conference URIs, or by generating URIs algorithmically), or probabilistically, (by creating a random URI with sufficiently low probabilities of collision).
会議URI、またはURI algorithmicallyを発生させる、)、probabilistically、(衝突の十分低い確率がある作成するのによる無作為の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.
セントラルサーバーで自動的に新しい会議を創設して、次にユーザをそれに置く会議アプリケーションにINVITEを送ることによって主催された会議を創設するのにSIPを使用できます。
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に接続された対話は、終点で接待された焦点にわたって、新たに接合された関係者に会議URIを渡すのに再INVITEかUPDATEを使用することです。
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.
あるいはまた、1UAが、終点で接待された会議を創設するように別のUAに頼むことができます。 これはSIP Joinヘッダー[10]と共に達成されます。 招待状でJoinヘッダーを受けるUAは、新しい会議URIを作成する必要があるかもしれません(新しいものは接合されている対話が既に会議の一部であるなら必要ではありません)。 そして、会議URIは再INVITEかUPDATEを通して最近接合された関係者に手渡されます。
5.2. Adding Participants
5.2. 関係者を加えます。
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はaであるなら会議URIを知りませんが、会議に関連づけられる対話に関して学びました。(対話イベントパッケージ、例えば、[11])を使用することによって、対話を接合するのにJoinヘッダーを使用することによって、UAは会議に参加できます。
Rosenberg Informational [Page 14] RFC 4353 Conferencing Framework with SIP February 2006
一口2006年2月があるローゼンバーグ情報[14ページ]のRFC4353会議枠組み
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要求を関係者に送ることができます、INVITE要求を会議URIに送るように彼らに頼んで。 さらに、INVITEを関係者に送るようにそれに頼んで、クライアントはREFER要求を焦点に送ることができます。 後者のテクニックには、クライアントがREFER方法を支持しない会議気づかない関係者を加えるのを許容する利益があります。
5.3. Removing Participants
5.3. 関係者を外します。
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を使用し終わることができます。
5.4. Destroying Conferences
5.4. コンファレンスを破壊します。
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をそれに送るのを試みるか、または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を送るでしょう。 同様に、何か会議通知サービスに申し込まれたユーザがいれば、それらの購読は実際の破壊の前にサーバによって終えられるでしょうに。
Rosenberg Informational [Page 15] RFC 4353 Conferencing Framework with SIP February 2006
一口2006年2月があるローゼンバーグ情報[15ページ]のRFC4353会議枠組み
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要求を使用して)、特に、会議は破壊されます。
5.5. Obtaining Membership Information
5.5. 会員資格情報を得ます。
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]ができます。
5.6. Adding and Removing Media
5.6. メディアを加えて、取り除きます。
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.
各会議は焦点が経営している特定のセットのメディアで構成されます。 例えば、会議はビデオストリームとオーディオストリームを含むかもしれません。 関係者は会議を構成するメディアの流れのセットを変えることができます。 会議変化におけるメディアのセットであるときに、焦点は、各関係者へのメディアの流れを加えるか、または取り除くために再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再INVITEを使用できます。 これはセッション[13]にメディアの流れを加えるのに標準の申し出/答えのテクニックを使用するのに優れています。 これはそれ自身の再INVITEsを発生させる焦点の引き金となるでしょう。
5.7. Conference Announcements and Recordings
5.7. コンファレンス発表と録音
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 点呼を支持するために会議に参加する前にそれらの名前を述べるようにユーザに頼みます。
Rosenberg Informational [Page 16] RFC 4353 Conferencing Framework with SIP February 2006
一口2006年2月があるローゼンバーグ情報[16ページ]のRFC4353会議枠組み
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
ユーザ1+-----------+ | | | | |関係者| | 1 | | | +-----------+ |一口|対話コンファレンス|1 方針+---|--------+ ユーザ2サーバ| | | アプリケーション+-----------+ +-----------+ | 非一口*************| | | | |-------- * * | | | | | * * |関係者|-----------| 焦点|------------*関係者*| 2 | 一口| | | 一口*4*| | 対話| |--+ 対話**+-----------+ 2 +-----------+ 4 ************* | | |一口|対話|3 | +-----------+ | | | | |関係者| | 3 | | | +-----------+ ユーザ3
Figure 3
図3
Rosenberg Informational [Page 17] RFC 4353 Conferencing Framework with SIP February 2006
一口2006年2月があるローゼンバーグ情報[17ページ]のRFC4353会議枠組み
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.
発表アプリケーションがすべての加盟会社に発表をプレーしたいなら(例えば、aを発表するには、接合してください)、それはいかなる他の関係者であるだろうことのようにも単にメディアをミキサーに送ります。 発表は、会話に複雑であり、関係者にプレーされます。
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]を使用できます。 これで、それは、ことによるとキーパッド刺激でユーザ入力を集めて、行動を取ります。
6. Physical Realization
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.
このセクションでは、私たちは、さまざまな問題を解決するためにどうこれらの基本機能を結合できるかを示しているためにこれらのコンポーネントのいくつかの物理的な具体化を提示します。
6.1. Centralized Server
6.1. 集結されたサーバ
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個の箱」の古典的な解決策です。
Rosenberg Informational [Page 18] RFC 4353 Conferencing Framework with SIP February 2006
一口2006年2月があるローゼンバーグ情報[18ページ]のRFC4353会議枠組み
Conference Server
...................................
. .
. +------------+ .
. | Conference | .
. |Notification| .
. | Server | .
. +------------+ .
. +----------+ .
. |Conference| +-----+ .
. | Policy | +-------+ +-----+| .
. | Server | | Focus | |Mixer|+ .
. +----------+ +-------+ +-----+ .
................//.\.....***.......
// \ *** *
// *** * RTP
SIP // *** \ *
// *** \SIP *
// *** RTP \ *
/ ** \ *
+-----------+ +-----------+
|Participant| |Participant|
+-----------+ +-----------+
コンファレンスサーバ… . . . +------------+ . . | コンファレンス| . . |通知| . . | サーバ| . . +------------+ . . +----------+ . . |コンファレンス| +-----+ . . | 方針| +-------+ +-----+| . . | サーバ| | 焦点| |ミキサー|+ . . +----------+ +-------+ +-----+ . ................//.\.....***....... //\****//****RTP一口//***\*//***\一口*//***RTP\*/**\*+-----------+ +-----------+ |関係者| |関係者| +-----------+ +-----------+
Figure 4
図4
6.2. Endpoint Server
6.2. 終点サーバ
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.
別の重要なモデルは局所的に複雑な臨時の会議のものです。 このシナリオには、2人のユーザ(AとB)が指す通常のポイント呼び出しでいます。 関係者(A)のひとりは3番目の関係者について中の会議に決めて、C.Toはこれをして、Aは焦点として機能し始めます。 Bがある既存の対話は焦点に付けられた最初の対話になります。 AはContact URIを焦点を特定する新しい値に変えるその対話の再INVITE Bがそうするでしょう。 本質では、焦点とシングルユーザーUAからシングルユーザーUAまでそのような変異(URI変化)の途中にAは「変異します」。 次に、焦点は外国行きのINVITEをCが受け入れるC.Whenにして、BとCからメディアを一緒に混ぜます、結果を再配付して。 また、混合媒体は局所的に対戦されます。 図5はこの変遷のダイヤグラムを示しています。
Rosenberg Informational [Page 19] RFC 4353 Conferencing Framework with SIP February 2006
一口2006年2月があるローゼンバーグ情報[19ページ]のRFC4353会議枠組み
B B
+------+ +------+
| | | |
| UA | | UA |
| | | |
+------+ +------+
| . | .
| . | .
| . | .
| . Transition | .
| . ------------> | .
SIP| .RTP SIP| .RTP
| . | .
| . | .
| . | .
| . | .
| . +----------+
+------+ | +------+ | SIP +------+
| | | |Focus | |----------| |
| UA | | |C.Pol.| | | UA |
| | | |Mixers| |..........| |
+------+ | | | | RTP +------+
| +------+ |
A | + | C
| + <..|.......
| + | .
| +------+ | .
| |Parti-| | .
| |cipant| | .
| | | | .
| +------+ | .
+----------+ .
A .
.
B B+------+ +------+ | | | | | Ua| | Ua| | | | | +------+ +------+ | . | . | . | . | . | . | . 変遷| . | . ------------>| . 一口| .RTP一口| .RTP| . | . | . | . | . | . | . | . | . +----------+ +------+ | +------+ | 一口+------+ | | | |焦点| |----------| | | Ua| | |C.老練な政治家、|| | Ua| | | | |ミキサー| |..........| | +------+ | | | | 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は会議方針と会議通知サービスを実行できました、彼らがそう望んでいたなら関係者が彼らに近づく手段を持っているのを許容して。 まさしく焦点がそうので、関係者と一緒にいるコレジデントは、振舞いと外部のインタフェースのどんな局面も変化すると言っていません。
Rosenberg Informational [Page 20] RFC 4353 Conferencing Framework with SIP February 2006
一口2006年2月があるローゼンバーグ情報[20ページ]のRFC4353会議枠組み
6.3. Media Server Component
6.3. メディアサーバコンポーネント
+------------+ +------------+
| App Server| SIP |Conf. Cmpnt.|
| |-------------| |
| Focus | non-SIP | Focus |
| C.Pol |-------------| C.Pol |
| | | Mixers |
|Notification| | |
| | | |
+------------+ +------------+
| \ .. .
| \\ RTP... .
| \\ .. .
| SIP \\ ... .
SIP | \\ ... .RTP
| ..\ .
| ... \\ .
| ... \\ .
| .. \\ .
| ... \\ .
| .. \ .
+-----------+ +-----------+
|Participant| |Participant|
+-----------+ +-----------+
+------------+ +------------+ | 装置サーバ| 一口|Conf。 Cmpnt、|| |-------------| | | 焦点| 非一口| 焦点| | C.老練な政治家|-------------| C.老練な政治家| | | | ミキサー| |通知| | | | | | | +------------+ +------------+ | \ .. . | \\RTP… . | \\ .. . | \\をちびちび飲んでください… . 一口| \\ ... .RTP| ..\ . | ... \\ . | ... \\ . | .. \\ . | ... \\ . | .. \ . +-----------+ +-----------+ |関係者| |関係者| +-----------+ +-----------+
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番目のサーバを利用します。 このサーバは、焦点を含んでいて、会議政策を実施しますが、会議通知サービスを全く持っていません。 会議方針は、トップレベル焦点からすべての招待状に応じるようにそれに言います。 アプリケーション・サーバーの焦点はそれぞれのユーザのメディアの流れを混合サーバに接続するのに第三者呼び出しコントロールを使用します、必要に応じて。 アプリケーション・サーバーの焦点がクライアントから会議方針制御コマンドを受け取るなら、それは、同じメディア方針制御コマンドをそれにすることによって、メディアサーバへそれを代表として派遣します。
Rosenberg Informational [Page 21] RFC 4353 Conferencing Framework with SIP February 2006
一口2006年2月があるローゼンバーグ情報[21ページ]のRFC4353会議フレームワーク
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.
このモデルは、混合サーバがさまざまな異なった会議アプリケーションにリソースとして使用されるのを許容します。 これはそれが会議方針に気づかないからです。 それが尋ねることなら何でもして、それは単に先端の平らなサーバへの「奴隷」です。
6.4. Distributed Mixing
6.4. 分配された混合
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関係者がいると、各関係者と焦点の間には、ただ一つの対話があるでしょうが、その対話に関連しているセッション記述は、メディアが関係者の中で配布されるのを許容するために構成されるでしょう。 これは図7に示されます。
Rosenberg Informational [Page 22] RFC 4353 Conferencing Framework with SIP February 2006
一口2006年2月があるローゼンバーグ情報[22ページ]のRFC4353会議フレームワーク
+---------+
|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|
+---------+ +---------+
+---------+ |Partcpnt| メディア| | メディア…| |.................. . | ミキサー| . . |C.Pol.Srv| . . +---------+ . . | . . | . . | . . 対話| . . | . . | . . | . . +---------+ . . |Cnf.Srvr、|| | . . | 焦点| . . |C.Pol.Srv| . . / | | \ . . / +---------+ \/、\/、\/対話、\/、\/対話、\/、\/、\/\+…---------+ +---------+ |Partcpnt| |Partcpnt| | | | | | | ......................... | | | ミキサー| | ミキサー| |C.Pol.Srv| メディア|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
混合のために各関係者にメディアを配布できるいくつかの方法があります。 マルチユニキャストモデルでは、各関係者は関係者に互いにメディアのコピーに行かせます。 この場合、セッション記述はN-1メディアストリームを管理します。マルチキャストモデルで、各関係者は一般的なマルチキャストグループに加わります、そして、各関係者はメディアストリームのただ一つのコピーをそのグループに送ります。 次に、基本的なマルチキャストインフラストラクチャがメディアを配布するので、各関係者はコピーを手に入れます。 単独のソースマルチキャストで
Rosenberg Informational [Page 23] RFC 4353 Conferencing Framework with SIP February 2006
一口2006年2月があるローゼンバーグ情報[23ページ]のRFC4353会議フレームワーク
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.
(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.
このモデルはユーザエージェントで追加機能性を必要とします。(そのエージェントは、出席しているかもしれません)。 したがって、関係者は焦点へのこの能力の広告を出すことができなければなりません。
6.5. Cascaded Mixers
6.5. どっと落しているミキサー
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に示されます。
Rosenberg Informational [Page 24] RFC 4353 Conferencing Framework with SIP February 2006
一口2006年2月があるローゼンバーグ情報[24ページ]のRFC4353会議フレームワーク
+---------+
+-----------------------| |------------------------+
| ++++++++++++++++++++| |++++++++++++++++++ |
| + +------| Focus |---------+ + |
| + | | | | + |
| + | +-| |--+ | + |
| + | | +---------+ | | + |
| + | | + | | + |
| + | | + | | + |
| + | | + | | + |
| + | | +---------+ | | + |
| + | | | | | | + |
| + | | | Mixer 2 | | | + |
| + | | | | | | + |
| + | | +---------+ | | + |
| + | |... . .... | | + |
| + .|....| . .|.... | + |
| + ...... | | . | ..|... + |
| + ... | | . | | ....+ |
| +---------+ | | +---------+ | | +---------+ |
| | | | | | | | | | | |
| | Mixer 2 | | | | Mixer 3 | | | | Mixer 4 | |
| | | | | | | | | | | |
| +---------+ | | +---------+ | | +---------+ |
| . . | | . . | | . . |
| . . | | .. . | | .. . |
| . . | | . . | | . . |
+---------+ . | +---------+ . | +---------+ . |
| Prtcpnt | . | | Prtcpnt | . | | Prtcpnt | . |
| 1 | . | | 3 | . | | 5 | . |
+---------+ . | +---------+ . | +---------+ . |
. | . | . |
+---------+ +---------+ +---------+
| Prtcpnt | | Prtcpnt | | Prtcpnt |
| 2 | | 4 | | 6 |
+---------+ +---------+ +---------+
+---------+ +-----------------------| |------------------------+ | ++++++++++++++++++++| |++++++++++++++++++ | | + +------| 焦点|---------+ + | | + | | | | + | | + | +-| |--+ | + | | + | | +---------+ | | + | | + | | + | | + | | + | | + | | + | | + | | + | | + | | + | | +---------+ | | + | | + | | | | | | + | | + | | | ミキサー2| | | + | | + | | | | | | + | | + | | +---------+ | | + | | + | |... . .... | | + | | + .|....| . .|.... | + | | + ...... | | . | ..|... + | | + ... | | . | | ....+ | | +---------+ | | +---------+ | | +---------+ | | | | | | | | | | | | | | | ミキサー2| | | | ミキサー3| | | | ミキサー4| | | | | | | | | | | | | | | +---------+ | | +---------+ | | +---------+ | | . . | | . . | | . . | | . . | | .. . | | .. . | | . . | | . . | | . . | +---------+ . | +---------+ . | +---------+ . | | Prtcpnt| . | | Prtcpnt| . | | Prtcpnt| . | | 1 | . | | 3 | . | | 5 | . | +---------+ . | +---------+ . | +---------+ . | . | . | . | +---------+ +---------+ +---------+ | Prtcpnt| | Prtcpnt| | Prtcpnt| | 2 | | 4 | | 6 | +---------+ +---------+ +---------+
------- SIP Dialog
....... Media Flow
+++++++ Control Protocol
------- 対話をちびちび飲んでください… メディア流れ+++++++制御プロトコル
Figure 8
エイト環
Rosenberg Informational [Page 25] RFC 4353 Conferencing Framework with SIP February 2006
一口2006年2月があるローゼンバーグ情報[25ページ]のRFC4353会議フレームワーク
7. Security Considerations
7. セキュリティ問題
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.
プライバシーは会議の重要な一面です。 だれも、静かに聴くために彼らが接合したのを知らない、ユーザは会議に参加したがっているかもしれません。 他のアプリケーションでは、関係者は他の関係者から彼らのアイデンティティだけを隠したがっているかもしれませんが、さもなければ、彼らの存在を彼らにお知らせください。 これらの機能は、会議システムによって提供される必要があります。
8. Contributors
8. 貢献者
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
同等のアラン・アンディ・Zmolekヨルク・オット・ダン・ジョンストンブライアンローゼンRohanマーイヘニングSchulzrinne Oritレヴィンロニトム・テイラーペトリKoskelainen Nermeenイスマイルピートリー
9. Acknowledgements
9. 承認
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.
作者は彼らのコメントについてメアリ・バーンズ、クリス・ボールトン、およびRohanマーイに感謝したがっています。 彼女のためのアリソン・マンキンのおかげで、このコメントとサポートは働いています。
Rosenberg Informational [Page 26] RFC 4353 Conferencing Framework with SIP February 2006
一口2006年2月があるローゼンバーグ情報[26ページ]のRFC4353会議フレームワーク
10. Informative References
10. 有益な参照
[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] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、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.、フレディリック、R.、およびV.ジェーコブソン、「RTP:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、STD64、RFC3550、2003年7月。
[3] Levin, O. and R. Even, "High-Level Requirements for Tightly
Coupled SIP Conferencing", RFC 4245, November 2005.
[3] レヴィン、O.、およびR.、同等である、「密結合一口会議のためのハイレベルの要件」、RFC4245、11月2005日
[4] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
[4] ローチ、A.、「セッション開始プロトコル(一口)特定のイベント通知」、RFC3265、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] ローゼンバーグ、J.、「セッション開始プロトコル(一口)におけるアプリケーション間連携のためのフレームワーク」が進歩、2005年2月に働いています。
[7] Johnston, A. and O. Levin, "Session Initiation Protocol (SIP)
Call Control - Conferencing for User Agents", Work in Progress,
February 2005.
[7] 「セッション開始プロトコル(一口)は、ユーザエージェントのためにコントロール--会議を召集する」というジョンストン、A.、およびO.レヴィンは進行中(2005年2月)で働いています。
[8] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
January 2005.
[8]バーナーズ・リー、T.、フィールディング、R.、およびL.Masinter、「Uniform Resource Identifier(URI):」 「ジェネリック構文」、STD66、RFC3986、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] ローゼンバーグ、J.、Schulzrinne、H.、およびP.Kyzivat、「ユーザを示して、セッション開始におけるエージェント能力は(一口)について議定書の中で述べます」、RFC3840、2004年8月。
[10] Mahy, R. and D. Petrie, "The Session Initiation Protocol (SIP)
"Join" Header", RFC 3911, October 2004.
2004年10月の[10] マーイ、R. and D.ピートリー、「「接合してください」というセッション開始プロトコル(一口)ヘッダー」RFC3911。
[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] ローゼンバーグ、J.、Schulzrinne、H.、およびR.マーイ、「招待はセッション開始プロトコル(一口)のために対話イベントパッケージを開始しました」、RFC4235、2005年11月。
[12] Sparks, R., "The Session Initiation Protocol (SIP) Refer
Method", RFC 3515, April 2003.
[12] スパークス、R.、「セッション開始プロトコル(一口)はメソッドを参照する」RFC3515、2003年4月。
[13] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002.
[13] ローゼンバーグとJ.とH.Schulzrinne、「セッション記述プロトコル(SDP)がある申し出/答えモデル」、RFC3264、2002年6月。
Rosenberg Informational [Page 27] RFC 4353 Conferencing Framework with SIP February 2006
一口2006年2月があるローゼンバーグ情報[27ページ]のRFC4353会議フレームワーク
[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] ローゼンバーグ、J.、ピーターソン、J.、Schulzrinne、H.、およびG.キャマリロ、「セッション開始という第三者呼び出しコントロール(3pcc)のための最も良い現在の実務は(一口)について議定書の中で述べます」、BCP85、RFC3725、2004年4月。
[15] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE
Method", RFC 3311, October 2002.
[15] ローゼンバーグ、J.、「セッション開始プロトコル(一口)アップデートメソッド」、RFC3311、2002年10月。
Author's Address
作者のアドレス
Jonathan Rosenberg Cisco Systems 600 Lanidex Plaza Parsippany, NJ 07054 US
ジョナサンローゼンバーグシスコシステムズ600Lanidex Plazaニュージャージー07054パーシッパニー(米国)
Phone: +1 973 952-5000 EMail: jdrosen@cisco.com URI: http://www.jdrosen.net
以下に電話をしてください。 +1 973 952-5000 メールしてください: jdrosen@cisco.com ユリ: http://www.jdrosen.net
Rosenberg Informational [Page 28] RFC 4353 Conferencing Framework with SIP February 2006
一口2006年2月があるローゼンバーグ情報[28ページ]のRFC4353会議フレームワーク
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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はこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Rosenberg Informational [Page 29]
ローゼンバーグInformationalです。[29ページ]
一覧
スポンサーリンク
