RFC4245 日本語訳
4245 High-Level Requirements for Tightly Coupled SIP Conferencing. O.Levin, R. Even. November 2005. (Format: TXT=24415 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group O. Levin
Request for Comments: 4245 Microsoft Corporation
Category: Informational R. Even
Polycom
November 2005
コメントを求めるワーキンググループO.レヴィンの要求をネットワークでつないでください: 4245年のマイクロソフト社カテゴリ: 情報の同等のR.Polycom2005年11月
High-Level Requirements for Tightly Coupled SIP Conferencing
密結合一口会議のためのハイレベルの要件
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 (2005).
Copyright(C)インターネット協会(2005)。
Abstract
要約
This document examines a wide range of conferencing requirements for tightly coupled SIP conferences. Separate documents will map the requirements to existing protocol primitives, define new protocol extensions, and introduce new protocols as needed. Together, these documents will provide a guide for building interoperable SIP conferencing applications.
このドキュメントは密結合SIP会議のためのさまざまな会議要件を調べます。 別々のドキュメントは、必要に応じて既存のプロトコル基関数に要件を写像して、新しいプロトコル拡大を定義して、新しいプロトコルを紹介するでしょう。 これらのドキュメントは共同利用できるSIP会議アプリケーションを組立てるためのガイドを一緒に、提供するでしょう。
Table of Contents
目次
1. Introduction ....................................................2
2. An Overview .....................................................2
3. High-Level Requirements .........................................3
3.1. Discovery Phase ............................................3
3.2. Conference Creation ........................................4
3.3. Conference Termination .....................................4
3.4. Participants' Manipulations ................................4
3.4.1. Participation of a Conference-Unaware User Agent ......5
3.4.2. Dial-Out Scenarios ....................................5
3.4.3. Dial-In Scenarios .....................................5
3.4.4. Third-Party Invitation to a Conference ................6
3.4.5. Participants' Removal .................................6
3.4.6. Participants' Privacy .................................6
3.5. Conference State Information ...............................7
3.5.1. Description ...........................................7
3.5.2. Dissemination of Changes ..............................7
3.5.3. On-demand Information Dissemination ...................8
3.6. Focus Role Migration .......................................8
1. 序論…2 2. 概要…2 3. ハイレベルの要件…3 3.1. 発見フェーズ…3 3.2. コンファレンス作成…4 3.3. コンファレンス終了…4 3.4. 関係者の操作…4 3.4.1. コンファレンス気づかないユーザエージェントの参加…5 3.4.2. ダイヤルアウトシナリオ…5 3.4.3. ダイヤルインのシナリオ…5 3.4.4. コンファレンスへの第三者招待…6 3.4.5. 関係者の取り外し…6 3.4.6. 関係者のプライバシー…6 3.5. コンファレンス州の情報…7 3.5.1. 記述…7 3.5.2. 変化の普及…7 3.5.3. 要求次第の情報普及…8 3.6. 役割の移行の焦点を合わせてください…8
Levin & Even Informational [Page 1] RFC 4245 Conferencing Requirements November 2005
レヴィンと[1ページ]情報のRFC4245会議要件2005年11月さえ
3.7. Side-bar Conferences .......................................8
3.8. Cascading of Conferences ...................................9
3.9. SIMPLE and SIP Conferencing Coordination ...................9
4. Security Considerations ........................................10
5. Contributors ...................................................10
6. References .....................................................10
6.1. Normative References ......................................10
3.7. サイドバーコンファレンス…8 3.8. コンファレンスをどっと落させています…9 3.9. 簡単、そして、一口会議コーディネート…9 4. セキュリティ問題…10 5. 貢献者…10 6. 参照…10 6.1. 標準の参照…10
1. Introduction
1. 序論
This document examines a wide range of conferencing requirements for tightly coupled SIP (RFC 3261 [2]) conferencing.
このドキュメントは密結合SIPのためのさまざまな会議要件を調べます。(RFC3261[2])会議。
The requirements are grouped by subjects in various areas allowing solutions to progress in parallel.
ソリューションが平行で進歩をするのを許容しながら、要件は様々な領域で対象によって分類されます。
Separate documents will map the requirements to existing protocol primitives, define new protocol extensions, and introduce new protocols as needed.
別々のドキュメントは、必要に応じて既存のプロトコル基関数に要件を写像して、新しいプロトコル拡大を定義して、新しいプロトコルを紹介するでしょう。
Together, these documents will provide a guide for building interoperable SIP conferencing applications.
これらのドキュメントは共同利用できるSIP会議アプリケーションを組立てるためのガイドを一緒に、提供するでしょう。
The terms "MAY", "SHOULD", and "MUST" are to be interpreted as described in RFC 2119 [1].
用語の「5月」、“SHOULD"、および“MUST"はRFC2119[1]で説明されるように解釈されることになっています。
2. An Overview
2. 概要
A SIP conference is an association of SIP user agents (i.e., conference participants) with a central point (i.e., a conference focus), where the focus has direct peer-wise relationships with the participants by maintaining a separate SIP dialog with each.
SIP会議は主要なポイント(すなわち、会議焦点)のSIPユーザエージェント(すなわち、会議の参加者)の協会です。(そこでは、焦点が、それぞれがある別々のSIP対話を維持することによって、関係者とのダイレクト同輩的な関係を持っています)。
The focus is a SIP user agent that has abilities to host SIP conferences including their creation, maintenance, and manipulation using SIP call control means and potentially other non-SIP means.
焦点はSIP呼び出しコントロール手段と潜在的に他の非SIP手段を使用することでそれらの作成、メインテナンス、および操作を含むホストSIP会議に才能があるSIPユーザエージェントです。
In this tightly coupled model, the SIP conference graph is always a star. The conference focus maintains the correlation among conference's dialogs internally.
この密結合モデルでは、いつもSIP会議グラフは星です。 会議焦点は会議の対話の中で内部的に相関関係を維持します。
The conference focus can be implemented either by a participant or by a separate application server.
関係者か別々のアプリケーション・サーバーは会議焦点を実装することができます。
In the first case, a focus is typically capable of hosting a simple ad hoc conference only. We envision that such basic conference can be established using SIP call control primitives only.
前者の場合、焦点は簡単な臨時の会議しか通常主催できません。 私たちは確立した使用がSIP呼び出しコントロール基関数専用であったかもしれないならそのあれほど基本的な会議を思い描きます。
Levin & Even Informational [Page 2] RFC 4245 Conferencing Requirements November 2005
レヴィンと[2ページ]情報のRFC4245会議要件2005年11月さえ
A dedicated conference server, in addition to the basic features, offers richer functionality including simultaneous conferences, large scalable conferences, reserved conferences, and managed conferences. A conferencing server can support any subset of the advanced conferencing functions presented in this document.
基本的特徴に加えて、同時の会議、大きいスケーラブルな会議、予約された会議、および管理された会議を含んでいて、ひたむきな会議サーバは、より豊かな機能性を提供します。 会議サーバは本書では提示された高度な会議機能のどんな部分集合もサポートできます。
The media graph of a SIP conference can be centralized, decentralized, or any combination of both, and potentially differ per media type. In the centralized case, the media sessions are established between the focus and each one of the participants. In the de-centralized (i.e., distributed) case, the media graph is a (multicast or multi-unicast) mesh among the participants. Consequently, the media processing (e.g., mixing) can be performed either by the focus alone or by the participants.
SIP会議のメディアグラフは、集結されて、分散されていて両方のどんな組み合わせでありも、メディアタイプ単位で潜在的に異なることができます。 集結された場合では、メディアセッションは関係者の焦点とそれぞれの間で確立されます。 分散している(すなわち、分配された)場合では、メディアグラフは関係者の中の(マルチキャストかマルチユニキャスト)メッシュです。 その結果、焦点だけか関係者がメディア処理(例えば、混合)を実行できます。
Conference participants and third parties can have different roles and privileges in a certain conference. For example, conferencing policy can state that the rights to disconnect from and to invite to a conference are limited to the conference chair only.
会議の参加者と第三者はある会議で異なる役割と特権を持つことができます。 例えば、会議方針は、切断して、会議に招待する権利が学会主催者だけに制限されると述べることができます。
Throughout the document, by conference policies we mean a set of parameters and rules (e.g., maximum number of participants, needs chair-person supervision or not, password protected or not, duration, or a way of media mixing) that are defined at the onset of a conference. Typically, conference policies would be specified by a conference creator and need special privileges to be manipulated.
ドキュメント中では、会議方針で、私たちは会議の開始のときに定義される1セットのパラメタと規則(例えば、最大数の関係者、パスワードは必要性議長指揮か否かに関係なく、保護されました、持続時間、またはメディアの道が混入して)を言っています。 会議方針は、通常、会議のクリエイターによって指定されて、特権が操られる必要があるでしょう。
Throughout the document, by a conference state we mean a set of information describing the conference in progress. This includes participants' information (such as dialog identifiers), media sessions in progress, the current loudest speaker, the current chair, etc.
ドキュメント中では、会議国で、私たちは進行中の会議について説明する1セットの情報を言っています。 これは関係者の情報(対話識別子などの)、進歩、現在の最もやかましいスピーカー、現在のいすのメディアセッションなどを含んでいます。
3. High-Level Requirements
3. ハイレベルの要件
In addition to the requirements presented in this document, supplementary requirements for conferencing policy, media mixing and other manipulations, floor control, privilege control, etc. will be discussed in separate documents.
本書では提示された要件に加えて、別々のドキュメントで会議方針、メディア混合、および他の操作のための補っている要件、床のコントロール、特権コントロールなどについて議論するでしょう。
3.1. Discovery Phase
3.1. 発見フェーズ
Some of the requirements presented in this section can be met either by configuration means or by using proprietary conventions. Nevertheless, there is consensus that standard means for implementing these functions by automata MUST be defined.
構成手段か独占コンベンションを使用することによって、このセクションに示された要件のいくつかに会うことができます。 それにもかかわらず、オートマトンでこれらの機能を実装するための標準の手段を定義しなければならないというコンセンサスがあります。
Levin & Even Informational [Page 3] RFC 4245 Conferencing Requirements November 2005
レヴィンと[3ページ]情報のRFC4245会議要件2005年11月さえ
REQ-1: Discovery of a location of an arbitrary SIP conferencing
server(s).
REQ-1: 任意のSIP会議サーバの位置の発見。
REQ-2: Given a SIP Address-of-Record (AOR) of a certain entity,
resolution whether the SIP entity has focus capabilities.
REQ-2: ある実体、解決記録のSIP Address(AOR)を考えて、SIP実体が焦点を合わせたか否かに関係なく、能力の焦点を合わせてください。
REQ-3: Given a global identifier of a particular conference, locating
the conference focus.
REQ-3: 特定の会議のグローバルな識別子を考えて、会議の場所を見つけて、集中してください。
REQ-4: Given a global identifier of a particular conference,
obtaining the conference properties.
REQ-4: 会議資産を入手して、特定の会議のグローバルな識別子を与えます。
REQ-5: Given a global identifier of a particular conference,
obtaining the conference state information.
REQ-5: 特定の会議のグローバルな識別子を考えて、会議を得て、情報を述べてください。
3.2. Conference Creation
3.2. コンファレンス作成
Given a focus location, a means MUST be defined for an interested entity (including a user agent) to implement the procedures below:
焦点の位置を考えて、関心がある実体(ユーザエージェントを含んでいる)が以下の手順を実装するように、手段を定義しなければなりません:
REQ-1: Creation of an ad-hoc conference identifier and the conference
with specified properties.
REQ-1: 臨時の会議識別子と指定された特性との会議の創設。
REQ-2: Creation of a reserved conference identifier for a conference
with specified properties.
REQ-2: 指定された特性との会議において、予約された会議識別子の作成。
REQ-3: Specifying properties upon conference creation in any of the
following ways: default, profiles, and explicitly.
REQ-3: 以下の方法のどれかに会議作成の特性を指定します: そして、デフォルト、プロフィール、明らかに。
3.3. Conference Termination
3.3. コンファレンス終了
REQ-1: Given a conference identifier, a means MUST be defined for a
user agent to disconnect all participants from the conference
and terminate the conference including the release of the
associated resources.
REQ-1: 会議識別子を考えて、ユーザエージェントが会議からすべての関係者から切断して、関連リソースのリリースを含む会議を終えるように、手段を定義しなければなりません。
REQ-2: A means MAY be defined for requesting a focus to revert a
two-party conference to a basic SIP point-to-point session
including the release of the associated conferencing resources.
REQ-2: 手段は、関連会議リソースのリリースを含む基本的なSIP二地点間セッションまでの2党議を振り向けるよう焦点に要求するために定義されるかもしれません。
3.4. Participants' Manipulations
3.4. 関係者の操作
Some of the requirements presented in this section can be met by
human intervention, configuration means, or proprietary
conventions. Nevertheless, there is consensus that standard
means for implementing these functions by automata MUST be
defined.
人間の介入、構成手段、または独占コンベンションがこのセクションに示された要件のいくつかに会うことができます。 それにもかかわらず、オートマトンでこれらの機能を実装するための標準の手段を定義しなければならないというコンセンサスがあります。
Levin & Even Informational [Page 4] RFC 4245 Conferencing Requirements November 2005
レヴィンと[4ページ]情報のRFC4245会議要件2005年11月さえ
3.4.1. Participation of a Conference-Unaware User Agent
3.4.1. コンファレンス気づかないユーザエージェントの参加
REQ-1: Focus MUST be able to invite and disconnect an RFC 3261
compliant only SIP user agent to and from a SIP conference.
REQ-1: 焦点は、RFCが3261であると言いなりになった状態で誘って、切断することができなければなりません。会議とSIP会議からのSIPユーザエージェントだけ。
REQ-2: An RFC 3261 compliant only SIP user agent MUST be able to
dial-in to a particular SIP conference. In this case, only the
human knows that he/she is connected to the conference.
REQ-2: RFC3261対応する、SIPユーザエージェントだけが特定のSIP会議へのダイヤルインにできるに違いありません。 この場合、人間だけが、その人が会議に接続されるのを知っています。
3.4.2. Dial-Out Scenarios
3.4.2. ダイヤルアウトシナリオ
REQ-1: A means MUST be defined for a focus to invite another user
agent to one of the focus' conferences. This procedure MUST
result in the establishment of a single SIP dialog between the
two.
REQ-1: 焦点が焦点の会議の1つに別のユーザエージェントを招待するように、手段を定義しなければなりません。 この手順は2つの間のただ一つのSIP対話の確立をもたらさなければなりません。
REQ-2: Given an existing SIP dialog between two user agents, if at
least one user agent has focus capabilities, a means MUST be
defined for the conference focus to invite the other user agent
to one of the focus' conferences without additional SIP dialog
establishment.
REQ-2: 2人のユーザエージェントの間の既存のSIP対話を考えて、少なくとも1人のユーザエージェントに焦点能力があるなら、会議焦点が追加SIP対話設立なしで焦点の会議の1つにもう片方のユーザエージェントを招待するように、手段を定義しなければなりません。
REQ-3: An invitation to a user agent to join a conference MUST
include a standard indication that it is a conference and the
conference identifier.
REQ-3: 会議に参加するユーザエージェントへの招待状はそれが会議と会議識別子であるという標準の指示を含まなければなりません。
3.4.3. Dial-In Scenarios
3.4.3. ダイヤルインのシナリオ
REQ-1: A means MUST be defined for a user agent to create an ad hoc
conference with default properties (as per "Conference Creation"
REQ-1 above) and to become a participant using a single SIP
dialog.
REQ-1: ユーザエージェントがデフォルトの特性(上の「コンファレンス作成」REQ-1に従って)との臨時の会議を創設して、ただ一つのSIP対話を使用することで関係者になるように手段を定義しなければなりません。
REQ-2: Given a reserved conference identifier, a means MUST be
defined for a user agent to activate the conference and to
become a participant using a single SIP dialog.
REQ-2: 予約された会議識別子を考えて、ユーザエージェントが会議を起動して、ただ一つのSIP対話を使用することで関係者になるように手段を定義しなければなりません。
REQ-3: Given a conference identifier of an active conference, a means
MUST be defined for a user agent to dial-in the conference and
to become a participant using a single SIP dialog between the
two.
REQ-3: そして、活発な会議に関する会議識別子を考えて、ユーザエージェントのために手段をダイヤルインと定義しなければならない、会議、2つの間のただ一つのSIP対話を使用することで関係者になるように。
REQ-4: Given an identifier of one of the dialogs of a particular
active conference, a means MUST be defined for a user agent to
dial-in the conference and to become a participant.
REQ-4: そして、特定の活発な会議の対話の1つに関する識別子を考えて、ユーザエージェントのために手段をダイヤルインと定義しなければならない、会議、関係者になるように。
Levin & Even Informational [Page 5] RFC 4245 Conferencing Requirements November 2005
レヴィンと[5ページ]情報のRFC4245会議要件2005年11月さえ
3.4.4. Third-Party Invitation to a Conference
3.4.4. コンファレンスへの第三者招待
REQ-1: Given a conference identifier, a means MUST be defined for a
user agent to invite another user agent to this conference.
REQ-1: 会議識別子を考えて、ユーザエージェントが別のユーザエージェントをこの会議に招待するように、手段を定義しなければなりません。
REQ-2: Given an identifier of one of the dialogs of a particular
active conference, a means MUST be defined for a user agent to
invite another user agent to this conference.
REQ-2: 特定の活発な会議の対話の1つに関する識別子を考えて、ユーザエージェントが別のユーザエージェントをこの会議に招待するように、手段を定義しなければなりません。
EQ-3: Given a conference identifier, a means SHOULD be defined for a
user agent to invite a list of user agents to this conference (a
so-called "mass invitation").
EQ-3: 会議識別子、手段SHOULDを考えて、定義されて、ユーザエージェントはこの会議(いわゆる「大規模招待」)にユーザエージェントのリストを招待してください。
3.4.5. Participants' Removal
3.4.5. 関係者の取り外し
REQ-1: A means MUST be defined for a conference focus to remove a
conference participant from the conference.
REQ-1: 会議焦点が会議から会議の参加者を外すように、手段を定義しなければなりません。
REQ-2: Given a conference identifier, a means MUST be defined for a
REQ-2: 会議識別子を考えて、aのために手段を定義しなければなりません。
user agent to remove a participant from the conference.
会議から関係者を外すユーザエージェント。
REQ-3: Given an identifier of one of the dialogs of a particular
active conference, a means MUST be defined for a user agent to
remove a participant from the conference.
REQ-3: 特定の活発な会議の対話の1つに関する識別子を考えて、ユーザエージェントが会議から関係者を外すように、手段を定義しなければなりません。
REQ-4: Given a conference identifier, a means MUST be defined for a
user agent to remove all the participants from the conference.
REQ-4: 会議識別子を考えて、ユーザエージェントが会議から参加者各位を外すように、手段を定義しなければなりません。
REQ-5: Given a conference identifier and a sub-list of participants,
a means MAY be defined for a user agent to remove the specified
participants from the conference (a so-called "mass ejection").
REQ-5: 関係者の会議識別子とサブリストを考えて、ユーザエージェントが会議(いわゆる「質量放出」)から指定された関係者を外すように、手段は定義されるかもしれません。
3.4.6. Participants' Privacy
3.4.6. 関係者のプライバシー
A conference focus SHOULD support the procedures described in this section. A conference participant MAY support the procedures described in this section. The requirements imply that "anonymizing" operations MUST be performed on all: the call control, the media control, and the media content when appropriate.
手順がこのセクションで説明した会議焦点SHOULDサポート。 会議の参加者はこのセクションで説明された手順をサポートするかもしれません。 要件は、「anonymizing」操作をすべてに実行しなければならないのを含意します: 呼び出しコントロール、メディアコントロール、および適切であると満足しているメディア。
REQ-1: A conference participant joins the conference "anonymously";
that is, his/her presence can be announced but without
disclosing his/her identity.
REQ-1: 会議の参加者は「匿名で」会議に参加します。 しかし、その人のアイデンティティを明らかにしないで、すなわち、その人の存在を示すことができます。
REQ-2: A conference participant requests a focus for anonymous
participation in the conference.
REQ-2: 会議の参加者は会議への匿名の参加のために焦点を要求します。
Levin & Even Informational [Page 6] RFC 4245 Conferencing Requirements November 2005
レヴィンと[6ページ]情報のRFC4245会議要件2005年11月さえ
REQ-3: A conference participant joins a conference in a "hidden
mode"; that is, his/her presence and identity are not to be
disclosed to other participants.
REQ-3: 会議の参加者は「隠されたモード」に会議に参加します。 すなわち、その人の存在とアイデンティティは他の関係者に明らかにされないことです。
REQ-4: A conference participant requests a focus for participation in
the conference in a hidden mode.
REQ-4: 会議の参加者は隠されたモードにおける会議への参加のために焦点を要求します。
3.5 Conference State Information
3.5 コンファレンス州の情報
3.5.1. Description
3.5.1. 記述
By a conference state, we mean a virtual database describing the conference in progress. This includes different conference aspects: participants' information (such as dialog identifiers and state), media sessions in progress (such as current stream contributing sources and encoding schemes), the current loudest speaker, the current chair, etc. Conference state is the latest conference snapshot triggered by changes in participants' state, conference policy changes, etc.
会議国で、私たちは進行中の会議について説明する仮想のデータベースを言っています。 これは異なった会議局面を含んでいます: 関係者の情報(対話識別子や状態などの)、進歩(ソースを寄付して、体系をコード化する現在のストリームなどの)、現在の最もやかましいスピーカー、現在のいすのメディアセッションなど コンファレンス状態が会議スナップが関係者の状態の変化で引き金となった最新のものである、会議方針は変化しますなど。
REQ-1: A conference state virtual database MUST have a modular
definition that is, it MUST be possible to access different
conference aspects independently.
REQ-1: 会議の州の仮想のデータベースには、モジュールの定義がなければなりません、すなわち、独自に異なった会議局面にアクセスするのは可能であるに違いありません。
REQ-2: It MUST be possible to aggregate information relating to
different conference aspects in a single report.
REQ-2: ただ一つのレポートの異なった会議局面に関連する情報に集めるのは可能であるに違いありません。
REQ-3: A mechanism for extensible definition and registration of
conference state evolving aspects MUST be present.
REQ-3: 局面を発展する会議状態の広げることができる定義と登録のためのメカニズムは存在していなければなりません。
REQ-4: A default conference state report MUST be defined. It SHOULD
contain a minimal useful set of information (e.g., a list of
current conference participants).
REQ-4: デフォルト会議州のレポートを定義しなければなりません。 それ、SHOULDは最小量の役に立つ情報(例えば、現在の会議の参加者のリスト)を含んでいます。
3.5.2. Dissemination of Changes
3.5.2. 変化の普及
REQ-1: A means MUST be defined for reporting the conference state
changes to interested parties (including non-conference
participants) in a timely manner.
REQ-1: 直ちに、利害関係者への会議州の変化(非会議の参加者を含んでいる)を報告するために手段を定義しなければなりません。
REQ-2: A means MUST be defined for a SIP user agent to express its
interest in selected state changes only.
REQ-2: SIPユーザエージェントが選択された州の変化だけへの関心を示すように、手段を定義しなければなりません。
REQ-3: A means MUST be defined for a SIP user agent to express the
minimum interval between receiving state change reports.
REQ-3: SIPユーザエージェントが受入国変更報告書の最小間隔を言い表すように、手段を定義しなければなりません。
REQ-4: It MUST be possible to aggregate recent changes in a single
reporting event.
REQ-4: ただ一つの報告イベントにおける最近の変化に集めるのは可能であるに違いありません。
Levin & Even Informational [Page 7] RFC 4245 Conferencing Requirements November 2005
レヴィンと[7ページ]情報のRFC4245会議要件2005年11月さえ
REQ-5: Default conference state change reports MUST be defined. They
SHOULD contain minimal useful to the participants information
(e.g., participants' joining and leaving the conference).
REQ-5: デフォルト会議州の変更報告書を定義しなければなりません。 それら、SHOULDが含んでいる、最小量、関係者情報(例えば、関係者の接合と会議を出る)の役に立ちます。
3.5.3. On-demand Information Dissemination
3.5.3. 要求次第の情報普及
REQ-1: A means MUST be defined to disseminate any conference state
information to interested parties (including SIP user agents)
on-demand.
REQ-1: 要求に応じて利害関係者(SIPユーザエージェントを含んでいます)にどんな会議州の情報も広めるために手段を定義しなければなりません。
REQ-2: A means MUST be defined for an interested party (including a
SIP user agent) to request conference state information of a
particular conference defined by the conference identifier.
REQ-2: 利害関係者(SIPユーザエージェントを含んでいる)が会議識別子によって定義された特定の会議の会議州の情報を要求するように、手段を定義しなければなりません。
REQ-3: A means MUST be defined for an interested party (including a
SIP user agent) to specify the subset of the conference state
information it wants and is capable of receiving.
REQ-3: 手段は、利害関係者(SIPユーザエージェントを含んでいる)がそれが欲しい会議州の情報の部分集合を指定するように定義しなければならなくて、受信できます。
3.6. Focus Role Migration
3.6. 焦点役割の移行
REQ-1: A procedure for delegating a focus role by the current focus
to another participant MUST be defined.
REQ-1: 現在の焦点のそばで焦点の役割を別の関係者へ代表として派遣するための手順を定義しなければなりません。
REQ-2: A procedure for requesting a conference focus to transfer its
role to another participant MUST be defined.
REQ-2: 別の関係者に役割を移すよう会議焦点に要求するための手順を定義しなければなりません。
REQ-3: A procedure for on-demand unconditional transfer of the focus
role to a different participant MUST be defined.
REQ-3: 異なった関係者への焦点の役割の要求次第の無条件譲渡のための手順を定義しなければなりません。
REQ-4: A detection procedure for a focus failure condition MUST be
defined.
REQ-4: 焦点失敗状態のための検出手順を定義しなければなりません。
3.7. Side-bar Conferences
3.7. サイドバーコンファレンス
A standard means MUST be defined in order to implement the operations defined in this section below.
下のこのセクションで定義された操作を実装するために標準の手段を定義しなければなりません。
REQ-1: A user agent (not a conference participant) joins a side-bar
within the conference by SIP means.
REQ-1: SIP手段でユーザエージェント(会議の参加者でない)は会議の中でサイドバーに加わります。
REQ-2: A user agent (not a conference participant) is invited to a
side-bar within the conference by SIP means.
REQ-2: ユーザエージェント(会議の参加者でない)は会議の中でSIP手段でサイドバーに招待されます。
REQ-3: A conference participant creates a side-bar conference with
one or more participants in a conference by SIP means.
REQ-3: 会議の参加者はSIP手段で会議の1人以上の関係者とのサイドバー会議を創設します。
REQ-4: A conference participant joins a side-bar within the
conference by SIP means.
REQ-4: SIP手段で会議の参加者は会議の中でサイドバーに加わります。
Levin & Even Informational [Page 8] RFC 4245 Conferencing Requirements November 2005
レヴィンと[8ページ]情報のRFC4245会議要件2005年11月さえ
REQ-5: A conference participant is invited to a side-bar within the
conference by SIP means.
REQ-5: 会議の参加者は会議の中でSIP手段でサイドバーに招待されます。
REQ-6: A conference-unaware user agent (a participant or not) creates
and participates in side-bar conferences. It MAY be achieved by
non-SIP means.
REQ-6: 会議気づかないユーザエージェント(関係者であるか否かに関係なく)は、サイドバー会議を創設して、参加します。 それは非SIP手段で達成されるかもしれません。
REQ-7: A conference participant creates side-bar conferences within
the conference without establishing any additional SIP dialogs
with the focus. It MAY be achieved by non-SIP means.
REQ-7: 焦点でどんな追加SIP対話も確立しないで、会議の参加者は会議の中にサイドバー会議を創設します。 それは非SIP手段で達成されるかもしれません。
REQ-8: A conference participant joins any number of side-bars within
the conference without establishing any additional SIP dialogs
with the focus. It MAY be achieved by non-SIP means.
REQ-8: 焦点でどんな追加SIP対話も確立しないで、会議の参加者は会議の中でいろいろなサイドバーに加わります。 それは非SIP手段で達成されるかもしれません。
REQ-9: A conference participant is invited to any number of side-bars
within the conference without establishing any additional SIP
dialogs with the focus. It MAY be achieved by non-SIP means.
REQ-9: 焦点でどんな追加SIP対話も確立しないで、会議の参加者は会議の中でいろいろなサイドバーに招待されます。 それは非SIP手段で達成されるかもしれません。
3.8. Cascading of Conferences
3.8. コンファレンスの滝
"Cascading of Conferences" is a term that has different meanings in different contexts. Some examples are listed below:
「コンファレンスの滝」は異なった文脈での異なった意味がある用語です。 いくつかの例が以下にリストアップされています:
- Peer-to-peer chaining of signaling. (Many ways exist to
build the media graph in this case.)
- シグナリングのピアツーピア推論。 (多くの道がこの場合メディアグラフを築き上げるために存在しています。)
- Conferences have hierarchal signaling relations. (Many ways
exists to build the media graph in this case.)
- コンファレンスには、聖職者階級制のシグナリング関係があります。 (多くの道がこの場合メディアグラフを築き上げるために存在しています。)
- "Cascading" is used to distribute the media "mixing" only.
The distribution of signaling is not required.
- 「滝」は、メディア「混合だけ」を分配するのに使用されます。 シグナリングの分配は必要ではありません。
As it can be seen from the examples, each will define a different set of requirements.
例から、それぞれが異なったセットの要件を定義するのを見ることができるので。
3.9. SIMPLE and SIP Conferencing Coordination
3.9. 簡単、そして、一口会議コーディネート
REQ-1: SIMPLE-based Presence and Instant Messaging architecture
SHOULD fit into the general SIP Conferencing architecture.
REQ-1: SIMPLEベースのPresenceとInstant MessagingアーキテクチャSHOULDは一般的なSIP Conferencingアーキテクチャに収まります。
REQ-2: A scenario where a multimedia SIP conference and a multiparty
instant messaging conversation take place among the same group
of participants MUST be addressed.
REQ-2: マルチメディアSIP会議と「マルチ-パーティー」インスタントメッセージングの会話が関係者の同じグループで行われるシナリオを扱わなければなりません。
REQ-3: A scenario where a side-bar and/or a sub-IM-conference is
being held as a part of SIP conference MUST be addressed.
REQ-3: サイドバー、そして/または、サブIMの会議がSIP会議の一部として行われているシナリオを扱わなければなりません。
Levin & Even Informational [Page 9] RFC 4245 Conferencing Requirements November 2005
レヴィンと[9ページ]情報のRFC4245会議要件2005年11月さえ
4. Security Considerations
4. セキュリティ問題
This document discusses high-level requirements for SIP conferencing. Conferencing has some specific security requirements, which will be summarized here at a very high level.
このドキュメントはSIP会議のためのハイレベルの要件について議論します。 会議には、いくつかの特定のセキュリティ要件があります。(要件はここ、非常に高いレベルでまとめられるでしょう)。
All of the operations and functions described in this document need to be authorized by a focus or a participant. It is expected that conferences will be governed by a set of authorization rules defined as a part of the conference policy. In order for the conference policy to be implemented, the focus needs to be able to authenticate potential participants. Normal SIP mechanisms including Digest authentication and certificates can be used [2]. These conference- specific security requirements will be discussed in detail in the protocol documents.
本書では説明された操作と機能のすべてが、焦点か関係者によって認可される必要があります。 会議が会議方針の一部と定義された1セットの承認規則で治められると予想されます。 会議政策が実施されるために、焦点は、潜在的関係者を認証できる必要があります。 Digest認証と証明書を含む正常なSIPメカニズムは中古の[2]であることができます。 プロトコルドキュメントで詳細にこれらの会議の特定のセキュリティ要件について議論するでしょう。
Conferencing also has privacy implications. Some of these are discussed in this document. Standard SIP mechanisms for a user agent to request privacy should be utilized by a focus and will be detailed in the protocol documents.
また、会議には、プライバシー意味があります。 本書ではこれらの或るものについて議論します。 ユーザエージェントがプライバシーを要求する標準のSIPメカニズムは、焦点によって利用されるべきであり、プロトコルドキュメントで詳細になるでしょう。
5. Contributors
5. 貢献者
This work is based on the discussions among the members of the SIP Conferencing design team.
この仕事はSIP Conferencingデザインチームのメンバーの中で議論に基づいています。
6. References
6. 参照
6.1. Normative References
6.1. 引用規格
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[1] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[2] 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.
[2] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
Levin & Even Informational [Page 10] RFC 4245 Conferencing Requirements November 2005
レヴィンと[10ページ]情報のRFC4245会議要件2005年11月さえ
Authors' Addresses
作者のアドレス
Orit Levin Microsoft Corporation One Microsoft Way Redmond, WA 98052
Oritレヴィンマイクロソフト社1マイクロソフト道、レッドモンド、ワシントン 98052
EMail: oritl@microsoft.com
メール: oritl@microsoft.com
Roni Even Polycom 94 Derech Em Hamoshavot Petach Tikva, Israel
ロニ同等のPolycom94DerechイエムHamoshavot Petach Tikva、イスラエル
EMail: roni.even@polycom.co.il
メール: roni.even@polycom.co.il
Levin & Even Informational [Page 11] RFC 4245 Conferencing Requirements November 2005
レヴィンと[11ページ]情報のRFC4245会議要件2005年11月さえ
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
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 currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Levin & Even Informational [Page 12]
レヴィンで情報でさえあります。[12ページ]
一覧
スポンサーリンク
