RFC4579 日本語訳
4579 Session Initiation Protocol (SIP) Call Control - Conferencing forUser Agents. A. Johnston, O. Levin. August 2006. (Format: TXT=96506 bytes) (Also BCP0119) (Status: BEST CURRENT PRACTICE)
プログラムでの自動翻訳です。
英語原文
Network Working Group A. Johnston
Request for Comments: 4579 Avaya
BCP: 119 O. Levin
Category: Best Current Practice Microsoft Corporation
August 2006
コメントを求めるワーキンググループA.ジョンストン要求をネットワークでつないでください: 4579Avaya BCP: 119O.レヴィンカテゴリ: 最も良い現在の練習マイクロソフト社2006年8月
Session Initiation Protocol (SIP)
Call Control - Conferencing for User Agents
セッション開始プロトコル(一口)呼び出しコントロール--ユーザエージェントのための会議
Status of This Memo
このメモの状態
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このドキュメントはインターネット共同体、要求議論、および提案のためのインターネットBest Current Practicesを改良に指定します。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
Abstract
要約
This specification defines conferencing call control features for the Session Initiation Protocol (SIP). This document builds on the Conferencing Requirements and Framework documents to define how a tightly coupled SIP conference works. The approach is explored from the perspective of different user agent (UA) types: conference- unaware, conference-aware, and focus UAs. The use of Uniform Resource Identifiers (URIs) in conferencing, OPTIONS for capabilities discovery, and call control using REFER are covered in detail with example call flow diagrams. The usage of the isfocus feature tag is defined.
この仕様はSession Initiationプロトコル(SIP)のための会議呼び出しコントロール機能を定義します。 このドキュメントは、密結合SIP会議がどう働いているかを定義するためにConferencing RequirementsとFrameworkドキュメントの上に建てられます。 アプローチは異なったユーザエージェント(UA)タイプの見解から調査されます: 会議気づかなくて、会議意識している、そして、焦点UAs。 コントロール使用REFERは例の呼び出しフローチャートで詳細にカバーされています。会議、能力発見のためのOPTIONSにおけるUniform Resource Identifier(URI)の使用、およびisfocus特徴タグの使用法が定義されるという要求。
Table of Contents
目次
1. Introduction ....................................................2
2. Terminology .....................................................3
3. SIP User Agent Conferencing Capability Types ....................3
3.1. Focus UA ...................................................4
3.2. Conference Factory URI .....................................4
3.3. Conference-Unaware UA ......................................5
3.4. Conference-Aware UA ........................................5
4. Usage of the 'isfocus' Feature Parameter ........................6
4.1. General ....................................................6
4.2. Session Establishment ......................................6
4.3. Discovery ..................................................7
5. SIP Conferencing Primitives .....................................7
5.1. INVITE: Joining a Conference Using the Conference
1. 序論…2 2. 用語…3 3. ユーザエージェント会議能力タイプをちびちび飲んでください…3 3.1. UAの焦点を合わせてください…4 3.2. コンファレンス工場のURI…4 3.3. コンファレンス気づかないUA…5 3.4. コンファレンス意識しているUA…5 4. 'isfocus'特徴パラメタの用法…6 4.1. 一般…6 4.2. セッション設立…6 4.3. 発見…7 5. 会議基関数をちびちび飲んでください…7 5.1. 招待します: コンファレンスを使用することでコンファレンスを接合します。
Johnston & Levin Best Current Practice [Page 1] RFC 4579 SIP CC Conferencing for UAs August 2006
ジョンストンとレヴィン最も良い現在の習慣[1ページ]RFC4579一口は2006年8月にUAsのために会議をCCします。
URI - Dial-In ..............................................7
5.2. INVITE: Adding a Participant by the Focus - Dial-Out ......11
5.3. INVITE: Manually Creating a Conference by Dialing
In to a Conferencing Application ..........................15
5.4. INVITE: Creating a Conference Using Ad-Hoc SIP Methods ....16
5.5. REFER: Requesting a Focus to Add a New Resource to
a Conference (Dial Out to a New Participant) ..............18
5.6. REFER: Requesting a User to Dial in to a Conference
Using a Conference URI ....................................21
5.7. REFER with REFER: Requesting a Focus to Refer a
Participant to Dial in to the Conference ..................23
5.8. Join Header Field: Dialing in to a Conference
Using a (3rd Party) Dialog Identifier .....................26
5.9. Replaces Header Field: Switching User Agents
within a Conference .......................................28
5.10. Replaces Header Field: Transferring a Point-to-Point
Session in to a Conference ...............................29
5.11. REFER with BYE: Requesting That the Focus Remove a
Participant from a Conference ............................31
5.12. Deleting a Conference ....................................33
5.13. Discovery of URI Properties Using OPTIONS ................34
6. Security Considerations ........................................36
7. Contributors ...................................................37
8. References .....................................................38
8.1. Normative References ......................................38
8.2. Informative References ....................................38
Appendix A: Creating a Conference by a Conference-Unaware UA.......40
URI--ダイヤルイン…7 5.2. 招待します: 焦点のそばのa関係者(ダイヤルアウト)を加えます…11 5.3. 招待します: 手動で、会議アプリケーションに直通電話にかけることによって、コンファレンスを作成します…15 5.4. 招待します: 臨時の一口メソッドを使用することでコンファレンスを作成します…16 5.5. 参照します: コンファレンス(新しい関係者への外では、ダイヤルする)に新しいリソースを加えるよう焦点に要求します…18 5.6. 参照します: コンファレンスURIを使用して、コンファレンスに直通電話にかけるようユーザに要求します…21 5.7. 参照する、参照します: コンファレンスに直通電話にかけるのに関係者を参照するよう焦点に要求します…23 5.8. ヘッダーフィールドを接合してください: (第3パーティ)対話識別子を使用することでコンファレンスに直通電話にかけます…26 5.9. ヘッダーフィールドを取り替えます: コンファレンスの中でユーザエージェントを切り換えます…28 5.10. ヘッダーフィールドを取り替えます: コンファレンスへの中の二地点間セッションを移します…29 5.11. さようならで、参照してください: 焦点がコンファレンスから関係者を外すよう要求します…31 5.12. コンファレンスを削除します…33 5.13. オプションを使用するURIの特性の発見…34 6. セキュリティ問題…36 7. 貢献者…37 8. 参照…38 8.1. 標準の参照…38 8.2. 有益な参照…38 付録A: コンファレンス気づかないUAはコンファレンスを作成します…40
1. Introduction
1. 序論
This specification uses the concepts and definitions from the high level requirements [14] and the SIP conferencing framework [8] documents. This approach is applicable to tightly coupled SIP conferences. In this architecture, a user agent (UA), known as a participant, establishes a SIP dialog with another UA, known as a focus. The focus is the central point of control, authentication, and authorization. This specification defines the operation of a focus and participant UAs. Note that only the signalling (SIP) needs to be centralized in this model; the media can be centrally mixed, distributed, or even multicast. For a full discussion of this architecture, see the SIP conferencing framework document [8].
この仕様は高い平らな要件[14]とSIP会議フレームワーク[8]ドキュメントから概念と定義を使用します。 このアプローチは密結合SIP会議に適切です。 このアーキテクチャに、関係者として知られているユーザエージェント(UA)は焦点として知られている別のUAと共にSIP対話を確立します。 焦点はコントロール、認証、および承認の主要なポイントです。 この仕様は焦点と関与しているUAsの操作を定義します。 合図(SIP)だけが、このモデルに集結される必要に注意してください。 メディアは中心に混ぜられたか、分配されたか、同等のマルチキャストであるかもしれません。 このアーキテクチャの十分な議論に関しては、SIP会議フレームワークドキュメント[8]を見てください。
The approach described in this document implements key functions in the conferencing framework using SIP primitives only. This allows for conducting simple conferences with defined functionalities using SIP mechanisms and conventions. Many other advanced functions can be implemented using additional means, but they are not in the scope of this document.
本書では説明されたアプローチは、SIP基関数だけを使用することで会議フレームワークにおける主要な機能を実装します。 これは、SIPメカニズムとコンベンションを使用する定義された機能性との簡単な会議を指導すると考慮します。 追加手段を使用することで他の多くの拡張機能を実装することができますが、それらはこのドキュメントの範囲にありません。
Johnston & Levin Best Current Practice [Page 2] RFC 4579 SIP CC Conferencing for UAs August 2006
ジョンストンとレヴィン最も良い現在の習慣[2ページ]RFC4579一口は2006年8月にUAsのために会議をCCします。
This document presents the basic call control (dial-in and dial-out) conferencing building blocks from the UA perspective. Possible applications include ad-hoc conferences and scheduled conferences.
このドキュメントが基本的な呼び出しコントロールを提示する、(ダイヤルイン、ダイヤルアウト) そして、UA見解からの会議ブロック。 可能なアプリケーションは臨時の会議と予定されている会議を含んでいます。
Note that a single conference can bridge participants that have different capabilities and who potentially have joined the conference by different means (i.e., dial-in, dial-out, scheduled, or ad-hoc).
ただ一つの会議が異なった手段で(すなわち、ダイヤルイン、予定されているダイヤルアウト臨時)で異なった能力を持って、潜在的に会議に参加した関係者をブリッジすることができることに注意してください。
The call control and dialog manipulation approach is based on the multiparty framework document [15]. That document defines the basic approach of service design adopted for SIP, which includes the following:
呼び出しコントロールと対話操作アプローチは「マルチ-パーティー」フレームワークドキュメント[15]に基づいています。 そのドキュメントは以下を含んでいるSIPのために採用されたサービスデザインの基本的なアプローチを定義します:
- Definition of primitives, not services
- Signaling model independent
- Invoker oriented
- Primitives make full use of URIs
- Include policies for authentication, authorization, logging, etc.
- Define graceful fallback to baseline SIP
- 基関数の定義、基関数がURIを完全に利用するという呼び出し元が適応させたどんなサービス(シグナリングモデル独立者)も認証、承認、伐採などのための方針を含んでいません。 - 優雅な後退を基線SIPと定義してください。
The use of opaque URIs and the ability to communicate call control context information within a URI (as opposed to using service-related header fields), as discussed in RFC 3087 [11], is fundamental to this approach.
不透明なURIの使用とURI(サービス関連のヘッダーフィールドを使用することと対照的に)の中で呼び出しコントロール文脈情報を伝える能力はRFC3087[11]で議論するようにこのアプローチに基本的です。
Capabilities discovery is an important feature of SIP systems, and conferencing systems can make use of such features. For a UA acting as a focus in a conference, this specification defines the usage of the 'isfocus' feature parameter.
能力発見はSIPシステムの重要な特徴です、そして、会議システムはそのような特徴を利用できます。 焦点として会議で機能するUAに関しては、この仕様は'isfocus'特徴パラメタの用法を定義します。
2. Terminology
2. 用語
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 and indicate requirement levels for compliant implementations [1].
本書では、キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは中でRFC2119について説明して、対応する実装[1]のために要件レベルを示すとき解釈されることであるべきですか?
3. SIP User Agent Conferencing Capability Types
3. 一口ユーザエージェント会議能力タイプ
From a conferencing perspective, the framework document outlines a number of possible different SIP components such as conference- unaware participant, conference-aware participant, and focus.
フレームワークドキュメントは会議の気づかない関与していて、会議意識している関係者や、焦点などの多くの可能な会議見解と、異なったSIPの部品について概説します。
This document applies the concepts above to the SIP call control part of the conferencing components. It defines normative behavior of the SIP UAs in various conferencing situations (referred to later as "scenarios").
このドキュメントは会議コンポーネントのSIP呼び出しコントロール部分への上記の概念を当てはまります。 それは様々な会議状況(後で「シナリオ」に言及される)における、SIP UAsの標準の動きを定義します。
Johnston & Levin Best Current Practice [Page 3] RFC 4579 SIP CC Conferencing for UAs August 2006
ジョンストンとレヴィン最も良い現在の習慣[3ページ]RFC4579一口は2006年8月にUAsのために会議をCCします。
3.1. Focus UA
3.1. 焦点UA
A focus, as defined in the framework, hosts a SIP conference and maintains a SIP signaling relationship with each participant in the conference. A focus contains a conference-aware user agent that supports the conferencing call control conventions as defined in this document.
フレームワークで定義される焦点は、会議の各関係者と共にSIP会議を主催して、SIPシグナリング関係を維持します。 焦点は本書では定義されるように会議呼び出しがコントロールコンベンションであるとサポートする会議意識しているユーザエージェントを含みます。
A focus SHOULD support the conference package RFC 4575 [9], behave as a notifier for that package, and indicate its support in the Allow- Events header fields in requests and responses. A focus MAY include information about the conference in Session Description Protocol (SDP) bodies sent as part of normal SIP signaling by populating the Session Information, URI, Email Address, and Phone Number SDP fields.
SHOULDが会議パッケージがRFC4575[9]であるとサポートして、そのパッケージのためのnotifierとして振る舞って、サポートを示すAllowイベントヘッダーが要求と応答でさばく焦点。 焦点は正常なSIPシグナリングの一部としてSession情報、URI、メールAddress、および電話Number SDP分野に居住することによって送られたSession記述プロトコル(SDP)本体に会議の情報を含むかもしれません。
In order to support advanced features, where a session established between two endpoints can migrate to a centralized conference, a focus SHOULD support the Replaces header field [6].
2つの終点の間で確立されたセッションが集結された会議にわたることができるところの焦点SHOULDを高度な特徴にサポートするには、Replacesがヘッダーフィールド[6]であるとサポートしてください。
A user agent with focus capabilities could be implemented in end user equipment and would be used for the creation of ad-hoc conferences.
焦点能力があるユーザエージェントは、エンドユーザ設備で実装することができて、臨時の会議の創設に使用されるでしょう。
A dedicated conferencing server, whose primary task is to simultaneously host conferences of arbitrary type and size, may allocate and publish a conference factory URI (as defined in the next section) for creating an arbitrary number of ad-hoc conferences (and subsequently their focuses) using SIP call control means.
ひたむきな会議サーバ(同時に任意のタイプとサイズのホスト会議にはプライマリタスクがある)は、SIP呼び出しコントロール手段を使用することで臨時の会議(そして、次にそれらの焦点)の特殊活字の数字を作成するために、会議工場のURI(次のセクションで定義されるように)を割り当てて、発行するかもしれません。
3.2. Conference Factory URI
3.2. コンファレンス工場のURI
According to the framework, there are many ways in which a conference can be created. A conferencing server implementation is free to choose from these methods, which include non-automated means (such as an Interactive Voice Response (IVR) system), SIP, or any conference control protocol.
フレームワークによると、会議を創設できる多くの方法があります。 会議サーバ実装はこれらのメソッドから自由に選ぶことができます。(メソッドは非自動化された手段(Interactive Voice Response(IVR)システムなどの)、SIP、またはどんな会議制御プロトコルも含んでいます)。
In order to automatically create an arbitrary number of ad-hoc conferences (and subsequently their focuses) using SIP call control means, a globally routable Conference Factory URI can be allocated and published.
SIP呼び出しコントロール手段を使用することで自動的に臨時の会議(そして、次にそれらの焦点)の特殊活字の数字を作成するために、グローバルに発送可能なコンファレンスFactory URIを割り当てて、発行できます。
A successful attempt to establish a call to this URI would result in the automatic creation of a new conference and its focus. As a result, note that the Conference Factory URI and the newly created focus URI MAY resolve to different physical devices.
このURIに呼び出しを確立するうまくいっている試みは新しい会議とその焦点の自動作成をもたらすでしょう。 その結果、コンファレンスFactory URIであって新たに作成されているのがURI5月の決心の異なったフィジカル・デバイスに焦点を合わせることに注意してください。
A scenario showing the use of the conference factory URI is shown in Section 5.4.
会議工場のURIの使用を示しているシナリオはセクション5.4に示されます。
Johnston & Levin Best Current Practice [Page 4] RFC 4579 SIP CC Conferencing for UAs August 2006
ジョンストンとレヴィン最も良い現在の習慣[4ページ]RFC4579一口は2006年8月にUAsのために会議をCCします。
3.3. Conference-Unaware UA
3.3. コンファレンス気づかないUA
The simplest user agent can participate in a conference ignoring all SIP conferencing-related information. The simplest user agent is able to dial in to a conference and to be invited to a conference. Any conferencing information is optionally conveyed to/from it using non-SIP means. Such a user agent would not usually host a conference (at least, not using SIP explicitly). A conference-unaware UA need only support RFC 3261 [2]. Call flows for conference-unaware UAs are not shown in general in this document as they would be identical to those in the SIP call flows document [13].
最も純真なユーザエージェントはすべてのSIPの会議関連の情報を無視する会議に参加できます。 最も純真なユーザエージェントは、会議に直通電話にかけて、会議に招待できます。 どんな会議情報も、非SIP手段を使用することでそれからの/に任意に伝えられます。 通常、そのようなユーザエージェントは会議を主催しないでしょう(少なくとも明らかにSIPを使用しません)。 会議気づかないUAは、RFC3261が[2]であるとサポートするだけでよいです。 ドキュメント[13]に会議気づかない本書では彼らがSIP呼び出しにおけるそれらと同じであるように一般に、UAsが見せられないのを流れのための流れに電話をしてください。
Note that the presence of an 'isfocus' feature tag in a Contact header field will not cause interoperability issues between a focus and a conference-unaware UA since it will be treated as an unknown header parameter and ignored, as per standard SIP behavior.
それが未知のヘッダーパラメタとして扱われて、標準のSIPの振舞いに従って無視されるので、Contactヘッダーフィールドにおける、'isfocus'特徴タグの存在が焦点と会議気づかないUAの間の相互運用性問題を引き起こさないことに注意してください。
3.4. Conference-Aware UA
3.4. コンファレンス意識しているUA
A conference-aware user agent supports SIP conferencing call control conventions defined in this document as a conference participant, in addition to support of RFC 3261 [2]. A conference-aware UA should be able to process SIP redirections such as described in Section 8.1.3.4 of RFC 3261.
会議意識しているユーザエージェントは、SIP会議呼び出しコントロールが本書では会議の参加者と定義されたコンベンションであるとサポートします、RFC3261[2]のサポートに加えて。 .4会議意識しているUAがセクション8.1.3で説明されるようにSIPリダイレクションを処理するはずであることができるのをRFC3261。
A conference-aware UA MUST recognize the 'isfocus' feature parameter. A conference-aware UA SHOULD support REFER [4], SIP events [3], and the conferencing package [9].
会議意識しているUaは'isfocus'特徴パラメタを認識しなければなりません。 会議意識しているUA SHOULDサポートREFER[4]、SIPイベント[3]、および会議は[9]をパッケージします。
A conference-aware UA SHOULD subscribe to the conference package if the 'isfocus' parameter is in the remote target URI of a dialog and if the conference package is listed by a focus in an Allow-Events header field. The SUBSCRIBE to the conference package SHOULD be sent outside any INVITE-initiated dialog. A termination of the INVITE dialog with a BYE does not necessarily terminate the SUBSCRIBE dialog.
会議意識している対話のリモート目標URIで'isfocus'パラメタがあって、会議パッケージがAllow-イベントヘッダーに焦点によって記載されるならUA SHOULDが会議パッケージに加入するのを分野。 会議パッケージSHOULD、登録、送られたいずれも外でINVITEによって開始された対話はそうです。 BYEとのINVITE対話の終了が必ず終わるというわけではない、登録、対話。
A conference-aware UA MAY render to the user any information about the conference obtained from the SIP header fields and SDP fields from the focus.
会議の会議意識しているUA MAYがいずれもユーザにするのを情報はSIPから焦点からヘッダーフィールドとSDP野原を得ました。
A conference-aware UA SHOULD render to the user any information about the conference obtained from the SIP conference package.
SIP会議パッケージから得られた会議の会議意識しているUA SHOULDがいずれもユーザにするのを情報。
Johnston & Levin Best Current Practice [Page 5] RFC 4579 SIP CC Conferencing for UAs August 2006
ジョンストンとレヴィン最も良い現在の習慣[5ページ]RFC4579一口は2006年8月にUAsのために会議をCCします。
4. Usage of the 'isfocus' Feature Parameter
4. 'isfocus'特徴パラメタの用法
4.1. General
4.1. 一般
The main design guidelines for the development of SIP extensions and conventions for conferencing are to define the minimum number of extensions and to have seamless backward compatibility with conference-unaware SIP UAs. The minimal requirement for SIP is being able to express that a dialog is a part of a certain conference referenced to by a URI. As a result of these extensions, it is possible to do the following using SIP:
SIP拡張子の開発のための主なデザインガイドラインと会議のためのコンベンションは、拡大の最小の数を定義して、会議気づかないSIP UAsとのシームレスの後方の互換性を持つことになっています。 SIPのための最小量の要件があります。URIは参照をつけられて、対話が、ある会議の一部であると言い表すことができます。 これらの拡大の結果、SIPを使用する以下をするのは可能です:
- Create a conference
- Join a conference
- Invite a user to a conference
- Expel a user by third party
- Discover if a URI is a conference URI
- Delete a conference
- 会議を創設してください--会議に参加してください--会議にユーザを招待してください--第三者はユーザを追放してください--URIが会議URIであるかどうか発見してください--会議を削除してください。
The approach taken is to use the feature parameter 'isfocus' to express that a SIP dialog belongs to a conference. The use of feature parameters in Contact header fields to describe the characteristics and capabilities of a UA is described in the User Agent Capabilities document [5], which includes the definition of the 'isfocus' feature parameter.
取られたアプローチはSIP対話が会議に属すと言い表すのに'isfocus'という特徴パラメタを使用することです。 特性について説明するContactヘッダーフィールドとUAの能力における特徴パラメタの使用はUserエージェントCapabilitiesドキュメント[5]で説明されます。(それは、'isfocus'特徴パラメタの定義を含んでいます)。
4.2. Session Establishment
4.2. セッション設立
In session establishment, a focus MUST include the 'isfocus' feature parameter in the Contact header field unless the focus wishes to hide the fact that it is a focus. To a participant, the feature parameter will be associated with the remote target URI of the dialog. It is an indication to a conference-aware UA that the resulting dialog belongs to a conference, identified by the URI in the Contact header field, and that the call control conventions defined in this document can be applied.
セッション設立では、焦点がそれが焦点であるという事実を隠したくない場合、焦点はContactヘッダーフィールドに'isfocus'特徴パラメタを含まなければなりません。 関係者にとって、特徴パラメタは対話のリモート目標URIに関連するでしょう。 それは会議意識しているUAへの結果として起こる対話がContactヘッダーフィールドにおけるURIによって特定された会議のものて、本書では定義された呼び出しコントロールコンベンションは適用できるという指示です。
By their nature, the conferences supported by this specification are centralized. Therefore, typically a conferencing system needs to allocate a SIP conference URI such that SIP requests to this URI are not forked and are routed to a dedicated conference focus. For example, a globally accessible SIP conference could be well constructed with a conference URI using a Globally Routable User Agent URI (GRUU) (defined in [16]), because of its ability to support the non-forking and global routability requirements.
本質的に、この仕様でサポートされた会議は集結されます。 したがって、通常、会議システムが、SIP会議URIを割り当てる必要があるので、このURIへのSIP要求は、股状でなく、ひたむきな会議焦点に発送されます。 例えば、会議URIがGlobally Routable UserエージェントURI(GRUU)を使用している状態で、グローバルにアクセスしやすいSIP会議をよく構成できました。(非分岐であってグローバルなroutabilityが要件であるとサポートする性能のために、[16])では、定義されています。
Johnston & Levin Best Current Practice [Page 6] RFC 4579 SIP CC Conferencing for UAs August 2006
ジョンストンとレヴィン最も良い現在の習慣[6ページ]RFC4579一口は2006年8月にUAsのために会議をCCします。
4.3. Discovery
4.3. 発見
Using the mechanism described in this section, it is possible, given an opaque URI, to determine if it belongs to a certain conference (i.e., meaning that it is a conference URI) or not. This discovery function can be implemented in SIP using an OPTIONS request, and can be done either inside an active dialog or outside a dialog. A focus MUST include the 'isfocus' feature parameter in a 200 OK response to an OPTIONS unless the focus wishes to hide the fact that it is a focus.
このセクションで説明されたメカニズムを使用して、不透明なURIを考えて、それは、それが、ある会議(すなわち、それが会議URIであることを意味する)に属すかどうか決定するために可能です。 この発見機能がSIPでOPTIONS要求を使用することで実装することができて、アクティブな対話の中、または、対話の外でできます。 焦点がそれが焦点であるという事実を隠したくない場合、焦点はOPTIONSへの200OK応答に'isfocus'特徴パラメタを含まなければなりません。
5. SIP Conferencing Primitives
5. 一口会議基関数
The SIP conferencing call control flows presented in this section are the call control building blocks for various SIP conferencing applications as described in the conferencing requirements [14] and framework [8] documents. The major design goal is that the same SIP conferencing primitives would be used by user agents having different conferencing capabilities and implementing different applications.
このセクションに示されたSIP会議呼び出しコントロール流れは会議要件[14]とフレームワーク[8]ドキュメントで説明されるように様々なSIP会議アプリケーションのための呼び出しコントロールブロックです。 主要なデザイン目標は同じSIP会議基関数が異なった会議能力を持って、異なったアプリケーションを実装するユーザエージェントによって使用されるだろうということです。
5.1. INVITE: Joining a Conference Using the Conference URI - Dial-In
5.1. 招待します: コンファレンスURIを使用することでコンファレンスを接合します--、ダイヤルイン
In this section, a user knows the conference URI and "dials in" to join this conference. The focus will authenticate the participant and apply authorization policy before allowing the participant to join the conference.
このセクションでは、ユーザは、会議URIを知って、この会議に参加するために「直通電話にかけます」。 焦点は、関係者が会議に参加するのを許容する前に、関係者を認証して、承認方針を適用するでしょう。
If the UA is the first participant of the conference to dial-in, it is likely that this INVITE will activate the focus and hence the conference. However, the conference URI must have been reserved prior to its use.
UAがダイヤルインへの会議の最初の関係者であるなら、このINVITEは焦点としたがって、会議を起動しそうでしょう。 しかしながら、会議URIは使用の前に予約されたに違いありません。
If the conference is up and running already, the dialing-in participant is joined to the conference by its focus.
会議が既に活動しているなら、直通電話にかける関係者は焦点によって会議で加わられます。
To join an existing specific conference, a UA will send an INVITE with the Request-URI set to the conference URI. The focus MUST include the 'isfocus' feature parameter in the Contact header field of the 200 OK response to the INVITE.
既存の特定の会議に参加するために、UAはRequest-URIセットがあるINVITEを会議URIに送るでしょう。 焦点はINVITEへの200OK応答のContactヘッダーフィールドに'isfocus'特徴パラメタを含まなければなりません。
Johnston & Levin Best Current Practice [Page 7] RFC 4579 SIP CC Conferencing for UAs August 2006
ジョンストンとレヴィン最も良い現在の習慣[7ページ]RFC4579一口は2006年8月にUAsのために会議をCCします。
An example call flow for joining a conference is shown in Figure 1.
会議に参加するための例の呼び出し流動は図1に示されます。
Alice Focus Bob Carol
| | |
| | Carol joins the conference |
| | |
| | INVITE sip:Conf-ID F1 |
| |<----------------------------------------|
| | 180 Ringing F2 |
| |---------------------------------------->|
| | 200 OK Contact:Conf-ID;isfocus F3 |
| |---------------------------------------->|
| | ACK F4 |
| |<----------------------------------------|
| | RTP |
| |<=======================================>|
| | SUBSCRIBE sip:Conf-ID F5 |
| |<----------------------------------------|
| | 200 OK F6 |
| |---------------------------------------->|
| | NOTIFY F7 |
| |---------------------------------------->|
| | 200 OK F8 |
| |<----------------------------------------|
アリス・焦点ボブ・キャロル| | | | | キャロルは会議に参加します。| | | | | | 一口: Conf-ID F1を招いてください。| | |<----------------------------------------| | | 180 F2を鳴らすこと。| | |---------------------------------------->| | | 200OK接触: Conf-ID; isfocus F3| | |---------------------------------------->| | | ACK F4| | |<----------------------------------------| | | RTP| | |<====================>|、|、| 一口: Conf-ID F5を申し込んでください。| | |<----------------------------------------| | | 200 OK F6| | |---------------------------------------->| | | F7に通知してください。| | |---------------------------------------->| | | 200 OK F8| | |<----------------------------------------|
Figure 1. A Participant Joins a Conference Using the Conference URI.
図1。 コンファレンスURIを使用することで関係者はコンファレンスに加わります。
F1 INVITE sip:3402934234@conf.example.com SIP/2.0
Via: SIP/2.0/UDP client.chicago.example.com
;branch=z9hG4bKhjhs8ass83
Max-Forwards: 70
To: <sip:3402934234@conf.example.com>
From: Carol <sip:carol@chicago.example.com>;tag=32331
Call-ID: d432fa84b4c76e66710
CSeq: 45 INVITE
Contact: <sip:carol@client.chicago.example.com>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
SUBSCRIBE, NOTIFY
Allow-Events: dialog
Accept: application/sdp, message/sipfrag
Supported: replaces
Content-Type: application/sdp
Content-Length: ...
F1 INVITE一口: 3402934234@conf.example.com SIP/2.0Via: SIP/2.0/UDP client.chicago.example.com; ブランチは前方へz9hG4bKhjhs8ass83マックスと等しいです: 70 To: <一口: 3402934234@conf.example.com 、gt;、From: キャロル<一口: carol@chicago.example.com 、gt;、; タグは32331呼び出しIDと等しいです: d432fa84b4c76e66710 CSeq: 45 接触を招いてください: <一口: carol@client.chicago.example.com 、gt;、許容します: 登録、招待、ACK、取り消してください、そして、オプション(さようなら)を参照して、イベントを許容して通知してください: 対話Accept: アプリケーション/sdp、メッセージ/sipfrag Supported: コンテントタイプを取り替えます: sdp Contentアプリケーション/長さ: ...
(SDP not shown)
(見せられなかったSDP)
Johnston & Levin Best Current Practice [Page 8] RFC 4579 SIP CC Conferencing for UAs August 2006
ジョンストンとレヴィン最も良い現在の習慣[8ページ]RFC4579一口は2006年8月にUAsのために会議をCCします。
F3 SIP/2.0 200 OK
Via: SIP/2.0/UDP client.chicago.example.com
;branch=z9hG4bKhjhs8ass83;received=192.0.2.4
To: <sip:3402934234@conf.example.com>;tag=733413
From: Carol <sip:carol@chicago.example.com>;tag=32331
Call-ID: d432fa84b4c76e66710
CSeq: 45 INVITE
Contact: <sip:3402934234@conf.example.com>;isfocus
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
SUBSCRIBE, NOTIFY
Allow-Events: dialog, conference
Accept: application/sdp, application/conference-info+xml,
message/sipfrag
Supported: replaces, join, gruu
Content-Type: application/sdp
Content-Length: ...
以下を通ってF3一口/2.0 200OK SIP/2.0/UDP client.chicago.example.com; ブランチはz9hG4bKhjhs8ass83と等しいです; =192.0.2.4To:を受けます。 <一口: 3402934234@conf.example.com 、gt;、;=733413From:にタグ付けをしてください キャロル<一口: carol@chicago.example.com 、gt;、; タグは32331呼び出しIDと等しいです: d432fa84b4c76e66710 CSeq: 45 接触を招いてください: <一口: 3402934234@conf.example.com 、gt;、;isfocusが以下を許容する 登録、招待、ACK、取り消してください、そして、オプション(さようなら)を参照して、イベントを許容して通知してください: 対話、会議Accept: アプリケーション/sdp、アプリケーション/会議インフォメーション+xml、メッセージ/sipfrag Supported: 取り替え、接合して、コンテントタイプをgruuする、: sdp Contentアプリケーション/長さ: ...
v=0
o=focus431 2890844526 2890842807 IN IP4 ms5.conf.example.com
s=-
i=Example Conference Hosted by Example.com
u=http://conf.example.com/3402934234
e=3402934234@conf-help.example.com
p=+1-888-2934234
c=IN IP4 ms5.conf.example.com
t=0 0
m=audio 49170 RTP/AVP 0
m=video 51372 RTP/AVP 31
v=0 o=focus431 2890844526 2890842807IN IP4 ms5.conf.example.com s=- iは0mのオーディオ49170RTP/AVP=ビデオ51372 0 0IN Example.com u= http://conf.example.com/3402934234 e= 3402934234@conf-help.example.com p=+1-888-2934234c=IP4 ms5.conf.example.com t=m=RTP/AVP31で例のコンファレンスHostedと等しいです。
F5 SUBSCRIBE sip:3402934234@conf.example.com SIP/2.0
Via: SIP/2.0/UDP client.chicago.example.com
;branch=z9hG4bKdf334
Max-Forwards: 70
To: <sip:3402934234@conf.example.com>
From: Carol <sip:carol@chicago.example.com>;tag=43524545
Call-ID: k3l43id034ksereree
CSeq: 22 SUBSCRIBE
Contact: <sip:carol@client.chicago.example.com>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
SUBSCRIBE, NOTIFY
Event: conference
Accept: application/conference-info+xml
Supported: replaces
Content-Length: 0
F5 SUBSCRIBE一口: 3402934234@conf.example.com SIP/2.0Via: SIP/2.0/UDP client.chicago.example.com; ブランチは前方へz9hG4bKdf334マックスと等しいです: 70 To: <一口: 3402934234@conf.example.com 、gt;、From: キャロル<一口: carol@chicago.example.com 、gt;、; タグは43524545呼び出しIDと等しいです: k3l43id034ksereree CSeq: 22 接触を申し込んでください: <一口: carol@client.chicago.example.com 、gt;、許容します: 登録、招待、ACK、取り消してください、そして、オプション(さようなら)を参照して、イベントに通知してください: 会議Accept: + アプリケーション/会議インフォメーションxml Supported: Content-長さを置き換えます: 0
Johnston & Levin Best Current Practice [Page 9] RFC 4579 SIP CC Conferencing for UAs August 2006
ジョンストンとレヴィン最も良い現在の習慣[9ページ]RFC4579一口は2006年8月にUAsのために会議をCCします。
F7 NOTIFY sip:carol@chicago.example.com SIP/2.0
Via: SIP/2.0/UDP ms5.conf.example.com;branch=z9hG4bK3343d1
Max-Forwards: 70
To: Carol <sip:carol@chicago.example.com>;tag=43524545
From: <sip:3402934234@conf.example.com>;tag=a3343df32
Call-ID: k3l43id034ksereree
CSeq: 34321 NOTIFY
Contact: <sip:3402934234@conf.example.com>;isfocus
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
SUBSCRIBE, NOTIFY
Event: conference
Accept: application/sdp, message/sipfrag
Subscription-State: active;expires=3600
Supported: replaces, join, gruu
Content-Type: application/conference-info+xml
F7 NOTIFY一口: carol@chicago.example.com SIP/2.0Via: 一口/2.0/UDP ms5.conf.example.com; ブランチは前方へz9hG4bK3343d1マックスと等しいです: 70 To: キャロル<一口: carol@chicago.example.com 、gt;、;=43524545From:にタグ付けをしてください <一口: 3402934234@conf.example.com 、gt;、; =a3343df32呼び出しIDにタグ付けをしてください: k3l43id034ksereree CSeq: 34321 接触に通知してください: <一口: 3402934234@conf.example.com 、gt;、;isfocusが以下を許容する 登録、招待、ACK、取り消してください、そして、オプション(さようなら)を参照して、イベントに通知してください: 会議Accept: アプリケーション/sdp、sipfrag Subscriptionメッセージ/州: 能動態; =3600Supportedを吐き出します: 取り替え、接合して、コンテントタイプをgruuする、: アプリケーション/会議インフォメーション+xml
Content-Length: ...
コンテンツの長さ: ...
<conference-info version="0" state="full"
entity="sip:3402934234@conf.example.com">
<conference-description>
<conf-uris>
<entry>
<uri>tel:+18882934234</uri>
</entry>
</conf-uris>
</conference-description>
<users>
<user entity="sip:carol@chicago.example.com" state="full">
<display-text>Carol</display-text>
<endpoint entity="sip:carol@client.chicago.example.com">
<status>connected</status>
<joining-method>dialed-in</joining-method>
<media id="1">
<display-text>Main Audio</display-text>
<type>audio</type>
<src-id>583398</src-id>
<status>sendrecv</status>
</media>
<media id="2">
<type>video</type>
<src-id>345212</src-id>
<status>sendrecv</status>
</media>
</endpoint>
</user>
</users>
</conference-info>
「<会議インフォメーションバージョン= いっぱいに「0インチは=を述べ」」という実体が「一口: 3402934234@conf.example.com 」と等しい、gt;、<会議記述><conf-uris><エントリー><uri>tel:; +18882934234 </uri></エントリー></conf-uris></会議-記述><ユーザ><ユーザ実体=「一口: carol@chicago.example.com 」が=を述べる、「完全な「テキスト>キャロル</ディスプレイ-テキストを表示している><>」; <終点実体=「一口: carol@client.chicago.example.com 」、gt;、<の状態の>の接続状態><接合</メソッド>は-中で</接合-メソッド><メディアイド=「1インチの><ディスプレイテキスト>Main」にダイヤルしました; オーディオ</ディスプレイ-テキスト><は>オーディオタイプ><src</イド>583398</src-イド><状態>sendrecv</状態></メディア><メディアイド=「2インチの>」をタイプします; <タイプ>ビデオタイプ><src</イド>345212</src-イド><状態>sendrecv</状態></メディア></終点>ユーザ></ユーザ></会議</インフォメーション>。
Johnston & Levin Best Current Practice [Page 10] RFC 4579 SIP CC Conferencing for UAs August 2006
ジョンストンとレヴィン最も良い現在の習慣[10ページ]RFC4579一口は2006年8月にUAsのために会議をCCします。
5.2. INVITE: Adding a Participant by the Focus - Dial-Out
5.2. 招待します: 焦点のそばで関係者を加えます--ダイヤルアウト
To directly add a participant to a conference, a focus SHOULD send an INVITE to the participant containing a Contact header field with the conference URI and the 'isfocus' feature parameter.
直接会議、焦点SHOULDに関係者を加えるには、会議URIがあるContactヘッダーフィールドと'isfocus'特徴パラメタを含む関係者にINVITEを送ってください。
Note that a conference-unaware UA would simply ignore the conferencing information and treat the session (from a SIP perspective) as a point-to-point session. This is because standard RFC 3261 [2] behavior is to ignore unknown header parameters such as 'isfocus'.
会議気づかないUAが二地点間セッションとして単に会議情報を無視して、セッション(SIP見解からの)を扱うことに注意してください。 これは標準のRFC3261[2]の振舞いが'isfocus'などの未知のヘッダーパラメタを無視することであるからです。
An example call flow is shown in Figure 2. It is assumed that Alice is already a participant of the conference. The focus invites Carol to the conference by sending an INVITE. After the session is established, Carol subscribes to the conference URI. It is important to note that there is no dependency on Carol's SUBSCRIBE (F5) and the NOTIFY to Alice (F9) -- they occur asynchronously and independently.
例の呼び出し流動は図2に示されます。 アリスが既に会議の関係者であると思われます。 焦点は、INVITEを送ることによって、会議にキャロルを招待します。 セッションが確立された後に、キャロルは会議URIに加入します。 登録、依存が全くキャロルのところにないことに注意するためには、アリス(F9)への(F5)とNOTIFY--非同期に独自に起こるのは重要です。
Johnston & Levin Best Current Practice [Page 11] RFC 4579 SIP CC Conferencing for UAs August 2006
ジョンストンとレヴィン最も良い現在の習慣[11ページ]RFC4579一口は2006年8月にUAsのために会議をCCします。
Alice Focus Bob Carol
| | | |
|<==================>| | |
| | |
| Focus "dials out" to add Carol to the conference |
| | |
| | INVITE Contact:Conf-ID;isfocus F1 |
| |---------------------------------------->|
| | 180 Ringing F2 |
| |<----------------------------------------|
| | 200 OK F3 |
| |<----------------------------------------|
| | ACK F4 |
| |---------------------------------------->|
| | RTP |
| |<=======================================>|
| | SUBSCRIBE sip:Conf-ID F5 |
| |<----------------------------------------|
| | 200 OK F6 |
| |---------------------------------------->|
| | NOTIFY F7 |
| |---------------------------------------->|
| | 200 OK F8 |
| |<----------------------------------------|
| NOTIFY F9 | |
|<-------------------| |
| 200 OK F10 | |
|------------------->| |
アリス・焦点ボブ・キャロル| | | | |<=========>|、|、|、|、|、|、| 焦点は、キャロルを会議に追加するために「アウトにダイヤルします」。| | | | | | 招待接触: Conf-ID; isfocus F1| | |---------------------------------------->| | | 180 F2を鳴らすこと。| | |<----------------------------------------| | | 200 OK F3| | |<----------------------------------------| | | ACK F4| | |---------------------------------------->| | | RTP| | |<====================>|、|、| 一口: Conf-ID F5を申し込んでください。| | |<----------------------------------------| | | 200 OK F6| | |---------------------------------------->| | | F7に通知してください。| | |---------------------------------------->| | | 200 OK F8| | |<----------------------------------------| | F9に通知してください。| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、| 200 OK F10| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|
Figure 2. A Focus "Dials Out" to Add a Participant to the Conference.
図2。 焦点は、コンファレンスに関係者を加えるために「アウトにダイヤルします」。
F7 NOTIFY sip:carol@chicago.example.com SIP/2.0
Via: SIP/2.0/UDP ms5.conf.example.com;branch=z9hG4bK3343d1
Max-Forwards: 70
To: Carol <sip:carol@chicago.example.com>;tag=43524545
From: <sip:3402934234@conf.example.com>;tag=a3343df32
Call-ID: k3l43id034ksereree
CSeq: 34321 NOTIFY
Contact: <sip:3402934234@conf.example.com>;isfocus
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
SUBSCRIBE, NOTIFY
Event: conference
Accept: application/sdp, message/sipfrag
Subscription-State: active;expires=3600
Supported: replaces, gruu
Content-Type: application/conference-info+xml
Content-Length: ...
F7 NOTIFY一口: carol@chicago.example.com SIP/2.0Via: 一口/2.0/UDP ms5.conf.example.com; ブランチは前方へz9hG4bK3343d1マックスと等しいです: 70 To: キャロル<一口: carol@chicago.example.com 、gt;、;=43524545From:にタグ付けをしてください <一口: 3402934234@conf.example.com 、gt;、; =a3343df32呼び出しIDにタグ付けをしてください: k3l43id034ksereree CSeq: 34321 接触に通知してください: <一口: 3402934234@conf.example.com 、gt;、;isfocusが以下を許容する 登録、招待、ACK、取り消してください、そして、オプション(さようなら)を参照して、出来事に通知してください: 会議Accept: アプリケーション/sdp、sipfrag Subscriptionメッセージ/州: 能動態; =3600Supportedを吐き出します: 取り替え、gruuコンテントタイプ: アプリケーション/会議インフォメーション+xml Content-長さ: ...
Johnston & Levin Best Current Practice [Page 12] RFC 4579 SIP CC Conferencing for UAs August 2006
ジョンストンとレヴィン最も良い現在の習慣[12ページ]RFC4579一口は2006年8月にUAsのために会議をCCします。
<conference-info version="0" state="full"
entity="sip:3402934234@conf.example.com">
<conference-description>
<conf-uris>
<entry>
<uri>tel:+18882934234</uri>
</entry>
</conf-uris>
</conference-description>
<users>
<user entity="sip:alice@atlanta.example.com" state="full">
<display-text>Alice</display-text>
<endpoint entity="sip:alice@client.atlanta.example.com">
<status>connected</status>
<joining-method>dialed-in</joining-method>
<media id="3">
<display-text>Main Audio</display-text>
<type>audio</type>
<src-id>647231</src-id>
<status>sendrecv</status>
</media>
<media id="4">
<type>video</type>
<src-id>21345</src-id>
<status>sendrecv</status>
</media>
</endpoint>
</user>
<user entity="sip:carol@chicago.example.com" state="full">
<display-text>Carol</display-text>
<endpoint entity="sip:carol@client.chicago.example.com">
<status>connected</status>
<joining-method>dialed-out</joining-method>
<media id="1">
<display-text>Main Audio</display-text>
<type>audio</type>
<src-id>583398</src-id>
<status>sendrecv</status>
</media>
<media id="2">
<type>video</type>
<src-id>345212</src-id>
<status>sendrecv</status>
</media>
</endpoint>
</user>
</users>
</conference-info>
「<会議インフォメーションバージョン= いっぱいに「0インチは=を述べ」」という実体が「一口: 3402934234@conf.example.com 」と等しい、gt;、<会議記述><conf-uris><エントリー><uri>tel:; +18882934234 </uri></エントリー></conf-uris></会議-記述><ユーザ><ユーザ実体=「一口: alice@atlanta.example.com 」状態が「完全な「テキスト>アリス</表示-テキストを表示している>の<><終点実体=」一口: alice@client.atlanta.example.com 」と等しい、gt;、<状態>は</状態>を接続しました; <接合方法>が「3インチのテキスト>Main Audio</表示-テキストを表示している>のタイプ>オーディオタイプ><src</イド>647231src</イド><状態>sendrecv</状態></メディア><メディア<><イド=」接合</方法><メディアイド=4インチ直通電話にかけた、> <タイプ>ビデオタイプ><src</イド>21345src</イド><状態>sendrecv</状態></メディア></終点></ユーザ><ユーザ実体が「一口: carol@chicago.example.com 」状態=と等しい、「完全な「テキスト>キャロル</表示-テキストを表示している><><終点」; 実体=「一口: carol@client.chicago.example.com 」、gt;、<の状態の>の接続状態><接合</方法のダイヤルされて出ている接合</方法><メディア>イドは「1インチのテキスト>Main Audio</表示-テキストを表示している>の<タイプ>オーディオタイプ><src</イド>583398src</イド><<>状態>sendrecv</sta」と等しいです。tus></メディア><メディアイドは「2インチの><タイプ>ビデオタイプ><src</イド>345212</src-イド><状態>sendrecv</状態></メディア></終点>ユーザ></ユーザ></会議</インフォメーション>」と等しいです。
Johnston & Levin Best Current Practice [Page 13] RFC 4579 SIP CC Conferencing for UAs August 2006
ジョンストンとレヴィン最も良い現在の習慣[13ページ]RFC4579一口は2006年8月にUAsのために会議をCCします。
F9 NOTIFY sip:alice@atlanta.example.com SIP/2.0
Via: SIP/2.0/UDP ms5.conf.example.com;branch=z9hG4bK3432
Max-Forwards: 70
To: Alice <sip:alice@atlanta.example.com>;tag=43524545
From: <sip:3402934234@conf.example.com>;tag=a3343df32
Call-ID: 8820450524545
CSeq: 998 NOTIFY
Contact: <sip:3402934234@conf.example.com>;isfocus
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
SUBSCRIBE, NOTIFY
Event: conference
Accept: application/sdp, message/sipfrag
Subscription-State: active;expires=2450
Supported: replaces, gruu
Content-Type: application/conference-info+xml
Content-Length: ...
F9 NOTIFY一口: alice@atlanta.example.com SIP/2.0Via: 一口/2.0/UDP ms5.conf.example.com; ブランチは前方へz9hG4bK3432マックスと等しいです: 70 To: アリス<一口: alice@atlanta.example.com 、gt;、;=43524545From:にタグ付けをしてください <一口: 3402934234@conf.example.com 、gt;、; =a3343df32呼び出しIDにタグ付けをしてください: 8820450524545CSeq: 998 接触に通知してください: <一口: 3402934234@conf.example.com 、gt;、;isfocusが以下を許容する 登録、招待、ACK、取り消してください、そして、オプション(さようなら)を参照して、出来事に通知してください: 会議Accept: アプリケーション/sdp、sipfrag Subscriptionメッセージ/州: 能動態; =2450Supportedを吐き出します: 取り替え、gruuコンテントタイプ: アプリケーション/会議インフォメーション+xml Content-長さ: ...
<conference-info version="1" state="partial"
entity="sip:3402934234@conf.example.com">
<users>
<user entity="sip:carol@chicago.example.com" state="full">
<display-text>Carol</display-text>
<endpoint entity="sip:carol@client.chicago.example.com">
<status>connected</status>
<joining-method>dialed-out</joining-method>
<media id="1">
<display-text>Main Audio</display-text>
<type>audio</type>
<src-id>583398</src-id>
<status>sendrecv</status>
</media>
<media id="2">
<type>video</type>
<src-id>345212</src-id>
<status>sendrecv</status>
</media>
</endpoint>
</user>
</users>
</conference-info>
「<会議インフォメーションバージョン=「1インチの状態=」部分的な」実体=「一口: 3402934234@conf.example.com 」、gt;、<ユーザ><ユーザ実体=「一口: carol@chicago.example.com 」が=を述べる、「完全な「テキスト>キャロル</表示-テキストを表示している><>」; <終点実体=「一口: carol@client.chicago.example.com 」、gt;、<の状態の>の接続状態><接合</方法>は-外で</接合-方法><メディアイド=「1インチの><表示テキスト>Main」にダイヤルしました; オーディオ</表示-テキスト><は>オーディオタイプ><src</イド>583398</src-イド><状態>sendrecv</状態></メディア><メディアイド=「2インチの>」をタイプします; <タイプ>ビデオタイプ><src</イド>345212</src-イド><状態>sendrecv</状態></メディア></終点>ユーザ></ユーザ></会議</インフォメーション>。
Johnston & Levin Best Current Practice [Page 14] RFC 4579 SIP CC Conferencing for UAs August 2006
ジョンストンとレヴィン最も良い現在の習慣[14ページ]RFC4579一口は2006年8月にUAsのために会議をCCします。
5.3. INVITE: Manually Creating a Conference by Dialing in to a
Conferencing Application
5.3. 招待します: 手動で、会議アプリケーションに直通電話にかけることによって、コンファレンスを作成します。
In this section, a user sends an INVITE to a conference server application. The application (such as an IVR system or a web page) is implemented because the system requires additional input from the user before it is able to create a conference. After a normal dialog is established, additional information is received and the conference together with its focus are created. Since the UA is now in a dialog with a focus, the focus will re-INVITE the user with the conference URI in Contact with the 'isfocus' feature parameter.
このセクションでは、ユーザは会議サーバ・アプリケーションにINVITEを送ります。 会議を創設できる前にシステムがユーザからの追加入力を必要とするので、アプリケーション(IVRシステムか1ウェブページなどの)は実行されます。 正常な対話が確立された後に、受け取られた追加情報と焦点に伴う会議は創設されます。 現在、対話にはUAが焦点をもってあるので、焦点は会議URIが'isfocus'特徴パラメタがあるContactにあるユーザの再INVITEがあるでしょう。
Alternatively, the additional information can be provided by the user during an early dialog (see RFC 3261 [2] for a discussion of early dialogs in SIP). This could be accomplished by a 183 Session Progress response sent by the conferencing application. After the conference is created, the conference URI would then be returned in a Contact in the 200 OK.
あるいはまた、ユーザは早めの対話の間、追加情報を提供できます(SIPでの早めの対話の議論のためのRFC3261[2]を見てください)。 これは応答が会議アプリケーションで送った183Session Progressによって達成されるかもしれません。 そして、会議を創設した後に、200OKのContactで会議URIを返すでしょう。
Note that since this flow is all about human interaction with a conferencing application, any errors and failures will be returned to the human (recorded announcements, error tones, etc.).
どんな誤りと失敗もこの流れが会議アプリケーションとの人間の交流に関するものであるので人間(記録された発表、誤りトーンなど)に返されることに注意してください。
As discussed in the conferencing framework, the conference URI must be unique across all distinct conferences within the same domain. In general, the user part of a conference URI will contain a pseudo random string.
会議枠組みで議論するように、会議URIは同じドメインの中のすべての異なった会議の向こう側にユニークであるに違いありません。 一般に、会議URIのユーザ部分は疑似無作為のストリングを含むでしょう。
An example call flow is shown in Figure 3. In this example, Alice uses a conference application that is triggered when Alice sends an INVITE to the conference application. In this example, Conf-App is used to represent the conference application URI. Alice's conference-aware UA learns of the existence of the conference from the 'isfocus' feature parameter and subscribes to the conference package to receive notifications of the conference state.
例の呼び出し流動は図3に示されます。 この例では、アリスはアリスが会議アプリケーションにINVITEを送ると引き起こされる会議アプリケーションを使用します。 この例では、Conf-装置は、会議アプリケーションURIを表すのに使用されます。 アリスの会議意識しているUAは、'isfocus'特徴パラメタから会議の存在を知って、会議状態の通知を受け取るために会議パッケージに加入します。
Johnston & Levin Best Current Practice [Page 15] RFC 4579 SIP CC Conferencing for UAs August 2006
ジョンストンとレヴィン最も良い現在の習慣[15ページ]RFC4579一口は2006年8月にUAsのために会議をCCします。
Alice Focus Bob Carol
| | | |
| Alice establishes session with conference application. |
| | | |
| INVITE sip:Conf-App F1 | |
|------------------->| | |
| 180 Ringing F2 | | |
|<-------------------| | |
| 200 OK F3 | | |
|<-------------------| | |
| ACK F4 | | |
|------------------->| | |
| RTP | | |
|<==================>| | |
| | | |
| Alice uses the application to create the conference. |
| | | |
| INVITE Contact:Conf-ID;isfocus F5 | |
|<-------------------| | |
| 200 OK F6 | | |
|------------------->| | |
| ACK F7 | | |
|<-------------------| | |
| RTP | | |
|<==================>| | |
| | | |
| SUBSCRIBE sip:Conf-ID F8 | |
|------------------->| | |
| 200 OK F9 | | |
|<-------------------| | |
| NOTIFY F10 | | |
|<-------------------| | |
| 200 OK F11 | | |
|------------------->| | |
アリス・焦点ボブ・キャロル| | | | | アリスは会議アプリケーションとのセッションを確立します。 | | | | | | 一口: Conf-装置F1を招いてください。| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| 180 F2を鳴らすこと。| | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、| 200 OK F3| | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、| ACK F4| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| RTP| | | |<=========>|、|、|、|、|、|、|、| アリスは、会議を創設するのにアプリケーションを使用します。 | | | | | | 招待接触: Conf-ID; isfocus F5| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、| 200 OK F6| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| ACK F7| | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、| RTP| | | |<=========>|、|、|、|、|、|、|、| 一口: Conf-ID F8を申し込んでください。| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| 200 OK F9| | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、| F10に通知してください。| | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、| 200 OK F11| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|
Figure 3. A Participant Creates a Conference Using an Application.
図3。 関係者は、アプリケーションを使用することでコンファレンスを作成します。
5.4. INVITE: Creating a Conference Using Ad-Hoc SIP Methods
5.4. 招待します: 臨時の一口方法を使用することでコンファレンスを作成します。
This section addresses creating a conference by using ad-hoc SIP means. The conference factory URI (as defined in Section 3.2) is used to automatically create the conference in this example. This is different from the previous scenario in that no human intervention is required -- an automaton can create the conference and add participants. Since the conference does not need to be scheduled or reserved, but is created "on the fly", it is an "ad-hoc" conference creation.
臨時のSIP手段を使用することによって会議を創設するこのセクションアドレス。 会議工場のURI(セクション3.2で定義されるように)は、自動的にこの例における会議を創設するのに使用されます。 これは前のシナリオと人間の介入は全く必要ではありません--オートマトンが会議を創設して、関係者を加えることができるという点において異なっています。 会議が予定されているか、または予約される必要はありませんが、「急いで」状態で創設されるので、それは「臨時」の会議創造です。
Johnston & Levin Best Current Practice [Page 16] RFC 4579 SIP CC Conferencing for UAs August 2006
ジョンストンとレヴィン最も良い現在の習慣[16ページ]RFC4579一口は2006年8月にUAsのために会議をCCします。
The benefit of this approach is that the conference URI need not be known to the user; instead it is created by a focus and used by the participants' UAs. The main difference between this scenario and Section 5.3 is that no user intervention (IVR, web page form, etc.) is required to create the conference.
このアプローチの恩恵は会議URIがユーザにとって知られている必要はないということです。 代わりに、それは、焦点によって作成されて、関係者のUAsによって使用されます。 このシナリオとセクション5.3の主な違いはユーザ介入(IVR、ウェブページフォームなど)は全く会議を創設するのに必要でないということです。
The SIP URI of the conference factory can be provisioned in the UA (as in a "create new conference" button on a SIP phone) or can be discovered using other means.
会議工場のSIP URIをUA(SIP電話の上の「新しい会議を創設してください」というボタンのように)で食糧を供給することができるか、または他の手段を使用していると発見できます。
A SIP entity (such as conferencing server) can distinguish this INVITE request as a request to create a new ad-hoc conference from a request to join an existing conference by the Request-URI. That is, although both requests may route to the same application, the differing services requested can be identified by the differing URIs in the request itself.
SIP実体(会議サーバなどの)はRequest-URIで既存の会議に参加するという要求から新しい臨時の会議を創設するという要求としてこのINVITE要求を区別できます。 すなわち、両方の要求ですが、要求自体における異なったURIで同じアプリケーションへのルート、サービスが要求した相違が特定できますように。
Assuming that all security and policy requirements have been met, a new conference will be created with the Contact URI returned in the 200 OK being the conference URI. The Contact header field MUST contain the 'isfocus' feature parameter to indicate that this URI is for a conference.
すべてのセキュリティと方針必要条件を満たしてあると仮定すると、新しい会議は会議URIである200OKでContact URIを返していて創設されるでしょう。 ContactヘッダーフィールドはこのURIが会議のためのものであることを示す'isfocus'特徴パラメタを含まなければなりません。
An example call flow is shown in Figure 4. Note that Conf-Factory is shorthand for the conference factory URI and Conf-ID Is short for the conference URI. In this flow, Alice has a conference-aware UA and creates a conference by sending an INVITE to the conference factory URI. The conference factory application creates the conference and redirects Alice to the focus using a 302 Moved Temporarily response. Note that with proxy recursion as part of normal RFC 3261 [2] behavior, Alice may never see the redirect but may just receive the responses from the focus starting with message F5. Once the media session is established, Alice subscribes to the conference URI obtained through the Contact in the 200 OK response from the focus.
例の呼び出し流動は図4に示されます。 Conf-工場が急に会議工場のURIとConf-ID Isへの会議URIのための速記であることに注意してください。 この流れでは、アリスは、会議意識しているUAを持って、会議工場のURIにINVITEを送ることによって、会議を創設します。 会議工場のアプリケーションは、302Moved Temporarily応答を使用することで会議を創設して、焦点にアリスを向け直します。 正常なRFC3261[2]の振舞いの一部としてのプロキシ再帰で、アリスが再直接を決して見ないかもしれないことに注意しますが、メッセージF5から始まって、焦点から応答をただ受けるかもしれません。 メディアセッションがいったん確立されると、アリスはContactを通して焦点から200OK応答で得られた会議URIに加入します。
Johnston & Levin Best Current Practice [Page 17] RFC 4579 SIP CC Conferencing for UAs August 2006
ジョンストンとレヴィン最も良い現在の習慣[17ページ]RFC4579一口は2006年8月にUAsのために会議をCCします。
Alice Conf-Factory App Focus Bob
| | | |
| Alice creates the conference. | |
| | | |
| INVITE sip:Conf-Factory F1 | |
|------------------->| | |
| 302 Moved Contact:Conf-ID;isfocus F2 | |
|<-------------------| | |
| ACK F3 | | |
|------------------->| | |
| INVITE sip:Conf-ID F4 | |
|---------------------------------------->| |
| 180 Ringing F5 | |
|<----------------------------------------| |
| 200 OK Contact:Conf-ID;isfocus F6 | |
|<----------------------------------------| |
| ACK F7 | |
|---------------------------------------->| |
| RTP | |
|<=======================================>| |
| | |
| Alice subscribes to the conference URI. | |
| | |
| SUBSCRIBE sip:Conf-ID F8 | |
|---------------------------------------->| |
| 200 OK F9 | |
|<----------------------------------------| |
| NOTIFY F10 | |
|<----------------------------------------| |
| 200 OK F11 | |
|---------------------------------------->| |
アリス・Conf-工場の装置焦点ボブ| | | | | アリスは会議を創設します。 | | | | | | | 一口: Conf-工場のF1を招いてください。| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| 302の動く接触: Conf-ID; isfocus F2| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、| ACK F3| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| 一口: Conf-ID F4を招待してください。| | |---------------------------------------->| | | 180 F5を鳴らすこと。| | |<----------------------------------------| | | 200OK接触: Conf-ID; isfocus F6| | |<----------------------------------------| | | ACK F7| | |---------------------------------------->| | | RTP| | |<====================>|、|、|、|、|、| アリスは会議URIに加入します。 | | | | | | 一口: Conf-ID F8を申し込んでください。| | |---------------------------------------->| | | 200 OK F9| | |<----------------------------------------| | | F10に通知してください。| | |<----------------------------------------| | | 200 OK F11| | |---------------------------------------->| |
Figure 4. Creation of a Conference Using SIP Ad-Hoc Methods.
図4。 一口の臨時の方法を使用するコンファレンスの創造。
5.5. REFER: Requesting a Focus to Add a New Resource to a Conference
(Dial Out to a New Participant)
5.5. 参照します: 新しいリソースをコンファレンスに加えるよう焦点に要求します。(新しい関係者へのダイヤル)
A SIP conference URI can be used to inject different kinds of information into the conference. Examples include new participants, new real-time media sources, new IM messages, and pointers to passive information references (such as HTTP URIs).
異種の情報を会議に注ぐのにSIP会議URIを使用できます。 例は新しい関係者、新しいリアルタイムのメディア・ソース、新しいIMメッセージ、およびポインタを受け身の情報参照(HTTP URIなどの)に含んでいます。
To request that the focus add a new information resource to the specified conference, any SIP UA can send a REFER to the conference URI with a Refer-To containing the URI of the new resource. Since this REFER is sent to the conference URI and not the conference factory URI, the semantics to the focus are to bring the resource into the conference and make it visible to the conference
焦点が新情報リソースを指定された会議に追加するよう要求するために、どんなSIP UAもaがある会議URIにREFERを送ることができる、Refer、-、新しいリソースのURIを含んでいます。 このREFERを会議に送るので、URIと会議工場のURIでない、焦点への意味論は、リソースを会議に運び込んで、それを会議に目に見えるようにすることです。
Johnston & Levin Best Current Practice [Page 18] RFC 4579 SIP CC Conferencing for UAs August 2006
ジョンストンとレヴィン最も良い現在の習慣[18ページ]RFC4579一口は2006年8月にUAsのために会議をCCします。
participants. The resultant focus procedures are dependent both on the nature of the new resource (as expressed by its URI) and the policy of the focus regarding IM, central vs. distributed real-time media processing, and so on.
関係者。 結果の焦点手順はIMに関して新しいリソース(URIによって言い表されるように)の本質と焦点の方針に依存しています、分配されたリアルタイムのメディア処理などに対して主要です。
The scenario for adding a new UA participant is important to support because it works even if the new participant does not support REFER and transfer call control -- only the requesting participant and the focus need to support the REFER and transfer call control.
新しいUA関係者を加えるためのシナリオは新しい関係者がREFERを支持し、呼び出しコントロールを移さないでも働いているので、支持するために重要です--要求している関係者と焦点だけが、REFERを支持して、呼び出しコントロールを移す必要があります。
Upon receipt of the REFER containing a Refer-To header with a SIP URI, the focus SHOULD send an INVITE to the new participant identified by the Refer-To SIP URI containing a Contact header field with the conference URI and the 'isfocus' feature parameter.
REFER含有を受け取り次第Refer、-、ヘッダー、SIP URIと共に、焦点SHOULDが特定された新しい関係者にINVITEを送る、Refer、-、会議URIがあるContactヘッダーフィールドを含むSIP URIと'isfocus'はパラメタを特徴とします。
A conference-unaware UA would simply ignore the conferencing information and treat the session (from a SIP perspective) as a point-to-point session.
会議気づかないUAは二地点間セッションとして単に会議情報を無視して、セッション(SIP見解からの)を扱うでしょう。
An example call flow is shown in Figure 5. While this flow shows the use of REFER to add a new participant to the conference, the mechanism can generally add a resource as identified by a URI to the conference. It is assumed that Alice is already a participant of the conference. Alice sends a REFER to the conference URI. The focus invites Carol to the conference by sending an INVITE. After the session is established, Carol subscribes to the conference URI. It is important to note that there is no dependency on Carol's SUBSCRIBE (F11) and the NOTIFY to Alice (F15) -- they occur asynchronously and independently.
例の呼び出し流動は図5に示されます。 この流れが新しい関係者を会議に追加するためにREFERの使用を示している間、一般に、メカニズムはURIによって会議に特定されるようにリソースを加えることができます。 アリスが既に会議の関係者であると思われます。 アリスは会議URIにREFERを送ります。 焦点は、INVITEを送ることによって、会議にキャロルを招待します。 セッションが確立された後に、キャロルは会議URIに加入します。 登録、依存が全くキャロルのところにないことに注意するためには、アリス(F15)への(F11)とNOTIFY--非同期に独自に起こるのは重要です。
Johnston & Levin Best Current Practice [Page 19] RFC 4579 SIP CC Conferencing for UAs August 2006
ジョンストンとレヴィン最も良い現在の習慣[19ページ]RFC4579一口は2006年8月にUAsのために会議をCCします。
Alice Focus Bob Carol
| | | |
|<==================>| | |
| REFER sip:Conf-ID Refer-To:Carol F1 | |
|------------------->| |
| 202 Accepted F2 | |
|<-------------------| |
| NOTIFY (Trying) F3 |
|<-------------------| |
| 200 OK F4 | |
|------------------->| |
| | |
| Focus "dials out" to join Carol to the conference |
| | |
| | INVITE Contact:Conf-ID;isfocus F5 |
| |---------------------------------------->|
| | 180 Ringing F6 |
| |<----------------------------------------|
| | 200 OK F7 |
| |<----------------------------------------|
| | ACK F8 |
| |---------------------------------------->|
| | RTP |
| |<=======================================>|
| NOTIFY (OK) F9 | |
|<-------------------| |
| 200 OK F10 | |
|------------------->| |
| | SUBSCRIBE sip:Conf-ID F11 |
| |<----------------------------------------|
| | 200 OK F12 |
| |---------------------------------------->|
| | NOTIFY F13 |
| |---------------------------------------->|
| | 200 OK F14 |
| |<----------------------------------------|
| NOTIFY F15 | |
|<-------------------| |
| 200 OK F16 | |
|------------------->| |
アリス・焦点ボブ・キャロル| | | | |<=========>|、|、|、| 一口: To: キャロルを参照しているConf-ID F1を参照してください。| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、| 202 受け入れられたF2| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、| (試みること)のF3に通知してください。| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、| 200 OK F4| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、|、|、| 焦点は、キャロルに会議で加わるために「アウトにダイヤルします」。| | | | | | 招待接触: Conf-ID; isfocus F5| | |---------------------------------------->| | | 180 F6を鳴らすこと。| | |<----------------------------------------| | | 200 OK F7| | |<----------------------------------------| | | ACK F8| | |---------------------------------------->| | | RTP| | |<====================>|、| (OK)F9に通知してください。| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、| 200 OK F10| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| 一口: Conf-ID F11を申し込んでください。| | |<----------------------------------------| | | 200 OK F12| | |---------------------------------------->| | | F13に通知してください。| | |---------------------------------------->| | | 200 OK F14| | |<----------------------------------------| | F15に通知してください。| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、| 200 OK F16| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|
Figure 5. Participant Requests That the Focus Add a Participant to
the Conference.
図5。 関係者は、焦点がコンファレンスに関係者を加えるよう要求します。
Johnston & Levin Best Current Practice [Page 20] RFC 4579 SIP CC Conferencing for UAs August 2006
ジョンストンとレヴィン最も良い現在の習慣[20ページ]RFC4579一口は2006年8月にUAsのために会議をCCします。
F1 REFER sip:3402934234@conf.example.com SIP/2.0
Via: SIP/2.0/UDP client.atlanta.example.com;branch=z9hG4bKg4534
Max-Forwards: 70
To: <sip:3402934234@conf.example.com>
From: Alice <sip:alice@atlanta.example.com>;tag=5534562
Call-ID: 849392fklgl43
CSeq: 476 REFER
Contact: <sip:alice@alice.example.com>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
SUBSCRIBE, NOTIFY
Accept: application/sdp, message/sipfrag
Refer-To: <sip:carol@chicago.example.com>
Supported: replaces
Content-Length: 0
F1 REFER一口: 3402934234@conf.example.com SIP/2.0Via: 一口/2.0/UDP client.atlanta.example.com; ブランチは前方へz9hG4bKg4534マックスと等しいです: 70 To: <一口: 3402934234@conf.example.com 、gt;、From: アリス<一口: alice@atlanta.example.com 、gt;、; タグは5534562呼び出しIDと等しいです: 849392fklgl43 CSeq: 476 接触を参照してください: <一口: alice@alice.example.com 、gt;、許容します: 招待、ACK、取り消してください、そして、オプション(さようなら)が参照される、登録、通知してください。受け入れてください: アプリケーション/sdp、sipfrag Referメッセージ/To: <一口: carol@chicago.example.com 、gt;、支持される: Content-長さを置き換えます: 0
5.6. REFER: Requesting a User to Dial in to a Conference Using a
Conference URI
5.6. 参照します: コンファレンスURIを使用して、コンファレンスに直通電話にかけるようユーザに要求します。
A participant wishing to add a new participant will request this participant to send an INVITE to the conference URI. This can be done using a non-SIP means (such as passing or publishing the conference URI in an email, IM, or web page). If a non-SIP means is used, then the flow and requirements are identical to Section 5.1.
新しい関係者を加えたがっている関係者は、会議URIにINVITEを送るようこの関係者に要求するでしょう。 これは非SIP手段(メール、IM、またはウェブページの会議URIを通るか、または発行などなどの)を使用し終わることができます。 非SIP手段が使用されているなら、流れと要件はセクション5.1と同じです。
The SIP mechanism to do this utilizes the REFER method.
これをするSIPメカニズムはREFER方法を利用します。
A UA wishing to add a new participant SHOULD send a REFER request to the participant with a Refer-To header containing the conference URI.
新しい関与しているSHOULDを加えたがっているA UAがREFER要求をaをもっている関係者に送る、Refer、-、会議URIを含むヘッダー。
The requirements are then identical to the dial-in case of Section 5.1. The inviting participant MAY receive notification through the REFER action that the new participant has been added in addition to the notification received through the conference package.
要件はその時、セクション5.1のダイヤルインのケースと同じです。 誘っている関係者は新しい関係者が会議パッケージを通して受け取られた通知に加えて加えられるというREFER動作による通知を受け取るかもしれません。
An example is shown in Figure 6. In this call flow, it is assumed that Alice is already a participant of the conference. Alice sends Bob an "out of band" REFER - that is, a REFER outside of an established dialog. Should Bob reject the REFER, Alice might try sending an INVITE to Bob to establish a session first, then send a REFER within the dialog, effectively transferring Bob into the conference [17].
例は図6に示されます。 この呼び出し流動では、アリスが既に会議の関係者であると思われます。 アリスは「バンド」REFER()をボブに送って、REFERは確立した対話の外部です。 ボブがREFERを拒絶するべきであり、アリスは、最初にセッションを証明するためにINVITEをボブに送ってみて、次に、対話の中でREFERを送るかもしれません、事実上、会議[17]にボブを移して。
Johnston & Levin Best Current Practice [Page 21] RFC 4579 SIP CC Conferencing for UAs August 2006
ジョンストンとレヴィン最も良い現在の習慣[21ページ]RFC4579一口は2006年8月にUAsのために会議をCCします。
Alice Focus Bob Carol
| | | |
|<==================>| | |
| | | |
| Alice adds Bob into conference | |
| | | |
| REFER Refer-To:Conf-ID F1 | |
|---------------------------------------->| |
| 202 Accepted F2 | | |
|<----------------------------------------| |
| NOTIFY (Trying) F3| | |
|<----------------------------------------| |
| 200 OK F4 | | |
|---------------------------------------->| |
| | INVITE sip:Conf-ID F5 |
| |<-------------------| |
| | 180 Ringing F6 | |
| |------------------->| |
| | 200 OK Contact:Conf-ID;isfocus F7 |
| |------------------->| |
| | ACK F8 | |
| |<-------------------| |
| | RTP | |
| |<==================>| |
| NOTIFY (OK) F9 | | |
|<----------------------------------------| |
| 200 OK F10 | | |
|---------------------------------------->| |
| NOTIFY F11 | | |
|<-------------------| | |
| 200 OK F12 | | |
|------------------->| | |
| | SUBSCRIBE sip:Conf-ID F13 |
| |<-------------------| |
| | 200 OK F14 | |
| |------------------->| |
| | NOTIFY F15 | |
| |------------------->| |
| | 200 OK F16 | |
| |<-------------------| |
アリス・焦点ボブ・キャロル| | | | |<=========>|、|、|、|、|、|、|、| アリスはボブを会議に追加します。| | | | | | | To: Conf-IDを参照しているF1を参照してください。| | |---------------------------------------->| | | 202 受け入れられたF2| | | |<----------------------------------------| | | (試みること)のF3に通知してください。| | | |<----------------------------------------| | | 200 OK F4| | | |---------------------------------------->| | | | 一口: Conf-ID F5を招待してください。| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、| 180 F6を鳴らすこと。| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| 200OK接触: Conf-ID; isfocus F7| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| ACK F8| | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、| RTP| | | |<=========>|、|、| (OK)F9に通知してください。| | | |<----------------------------------------| | | 200 OK F10| | | |---------------------------------------->| | | F11に通知してください。| | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、| 200 OK F12| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、|、| 一口: Conf-ID F13を申し込んでください。| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、| 200 OK F14| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| F15に通知してください。| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| 200 OK F16| | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|
Figure 6. Adding a Participant to an Existing Conference.
図6。 既存のコンファレンスに関係者を加えます。
Johnston & Levin Best Current Practice [Page 22] RFC 4579 SIP CC Conferencing for UAs August 2006
ジョンストンとレヴィン最も良い現在の習慣[22ページ]RFC4579一口は2006年8月にUAsのために会議をCCします。
5.7. REFER with REFER: Requesting a Focus to Refer a Participant to
Dial in to the Conference
5.7. 参照する、参照します: コンファレンスに直通電話にかけるのに関係者を参照するよう焦点に要求します。
A participant may request that the focus refer a participant into the conference by sending a REFER method. The Refer-To header field will have the method set to REFER and an escaped Refer-To header field containing the conference URI.
関係者は、焦点がREFER方法を送ることによって関係者を会議に差し向けるよう要求するかもしれません。 そして、Refer、-、ヘッダーフィールドでREFERに方法を設定する、エスケープ、Refer、-、会議URIを含むヘッダーフィールド。
Note that in Message F1 below, the Refer-To header field is shown as continuing across two lines -- this would not be the case in an actual message; the URI would have continued beyond the formatting limitations of this document.
以下のMessage F1でそれに注意してください、Refer、-、ヘッダーフィールドは2つの線の向こう側に続くとして示されます--これは実際のメッセージでそうでないでしょう。 URIはこのドキュメントの形式限界を超えて続いたでしょう。
This scenario is shown in Figure 7.
このシナリオは図7に示されます。
Johnston & Levin Best Current Practice [Page 23] RFC 4579 SIP CC Conferencing for UAs August 2006
ジョンストンとレヴィン最も良い現在の習慣[23ページ]RFC4579一口は2006年8月にUAsのために会議をCCします。
Alice Focus Bob Carol
| | | |
|<==================>| | |
| Alice asks focus to REFER Bob into conference |
| | | |
|REFER sip:Conf-ID Refer-To:Bob;method=REFER?Refer-To=Conf-ID F1
|------------------->| | |
| 202 Accepted F2 | | |
|<-------------------| | |
| NOTIFY (Trying) F3| | |
|<-------------------| | |
| 200 OK F4 | | |
|------------------->| | |
| Focus REFERs Bob to the conference |
| | | |
| | REFER Refer-To:Conf-ID F5 |
| |------------------->| |
| | 202 Accepted F6 | |
| NOTIFY (202) F7 |<-------------------| |
|<-------------------| NOTIFY (Trying) F8 | |
| 200 OK F9 |<-------------------| |
|------------------->| 200 OK F10 | |
| |------------------->| |
| | INVITE sip:Conf-ID F11 |
| |<-------------------| |
| | 180 Ringing F12 | |
| |------------------->| |
| | 200 OK Contact:Conf-ID;isfocus F13 |
| |------------------->| |
| | ACK F14 | |
| NOTIFY F15 |<-------------------| |
|<-------------------| RTP | |
| 200 OK F16 |<==================>| |
|------------------->| NOTIFY (200) F17 | |
| |<-------------------| |
| | 200 OK F18 | |
| |------------------->| |
| | SUBSCRIBE sip:Conf-ID F17 |
| |<-------------------| |
| | 200 OK F19 | |
| |------------------->| |
| | NOTIFY F20 | |
| |------------------->| |
| | 200 OK F21 | |
| |<-------------------| |
アリス・焦点ボブ・キャロル| | | | |<=========>|、|、|、| アリスは会議へのREFERボブに焦点を招きます。| | | | | |一口: To:を参照しているConf-IDボブを参照してください; 方法=は参照されます--=Conf IDを参照してください、F1|、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| 202 受け入れられたF2| | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、| (試みること)のF3に通知してください。| | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、| 200 OK F4| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| REFERsボブの会議に焦点を合わせてください。| | | | | | | To: Conf-IDを参照しているF5を参照してください。| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| 202 受け入れられたF6| | | (202) F7に通知してください。| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| (試みること)のF8に通知してください。| | | 200 OK F9| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| 200 OK F10| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| 一口: Conf-ID F11を招待してください。| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、| 180 F12を鳴らすこと。| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| 200OK接触: Conf-ID; isfocus F13| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| ACK F14| | | F15に通知してください。| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| RTP| | | 200 OK F16|<=========>|、| |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| (200) F17に通知してください。| | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、| 200 OK F18| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| 一口: Conf-ID F17を申し込んでください。| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、| 200 OK F19| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| F20に通知してください。| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| 200 OK F21| | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|
Figure 7. Requesting That the Focus Refer a Participant to a
Conference.
図7。 焦点が関係者をコンファレンスに差し向けるよう要求します。
Johnston & Levin Best Current Practice [Page 24] RFC 4579 SIP CC Conferencing for UAs August 2006
ジョンストンとレヴィン最も良い現在の習慣[24ページ]RFC4579一口は2006年8月にUAsのために会議をCCします。
F1 REFER sip:3402934234@conf.example.com SIP/2.0
Via: SIP/2.0/UDP client.atlanta.example.com;branch=z9hG4bKg4534
Max-Forwards: 70
To: <sip:3402934234@conf.example.com>
From: Alice <sip:alice@atlanta.example.com>;tag=5534562
Call-ID: 849392fklgl43
CSeq: 476 REFER
Contact: <sip:alice@alice.example.com>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
SUBSCRIBE, NOTIFY
Accept: application/sdp, message/sipfrag
Refer-To: <sip:bob@biloxi.example.com;method=REFER
?Refer-To=sip:3402934234%40example.com>
Supported: replaces
Content-Length: 0
F1 REFER一口: 3402934234@conf.example.com SIP/2.0Via: 一口/2.0/UDP client.atlanta.example.com; ブランチは前方へz9hG4bKg4534マックスと等しいです: 70 To: <一口: 3402934234@conf.example.com 、gt;、From: アリス<一口: alice@atlanta.example.com 、gt;、; タグは5534562呼び出しIDと等しいです: 849392fklgl43 CSeq: 476 接触を参照してください: <一口: alice@alice.example.com 、gt;、許容します: 招待、ACK、取り消してください、そして、オプション(さようなら)が参照される、登録、通知してください。受け入れてください: アプリケーション/sdp、sipfrag Referメッセージ/To: <一口: bob@biloxi.example.com;method =は参照されます--=一口: 40example.com>が支持した3402934234%を参照してください: Content-長さを置き換えます: 0
F5 REFER sip:3402934234@conf.example.com SIP/2.0
Via: SIP/2.0/UDP ms5.conf.example.com;branch=z9hG4bK33445243
Max-Forwards: 70
To: <sip:bob@biloxi.example.com>
From: <sip:3402934234@conf.example.com>;tag=345621412
Call-ID: 5494204
CSeq: 4524323 REFER
Contact: <sip:3402934234@conf.example.com>;isfocus
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
SUBSCRIBE, NOTIFY
Accept: application/sdp, message/sipfrag
Refer-To: <sip:3402934234@conf.example.com>
Supported: join, gruu, replaces
Content-Length: 0
F5 REFER一口: 3402934234@conf.example.com SIP/2.0Via: 一口/2.0/UDP ms5.conf.example.com; ブランチは前方へz9hG4bK33445243マックスと等しいです: 70 To: <一口: bob@biloxi.example.com 、gt;、From: <一口: 3402934234@conf.example.com 、gt;、; タグは345621412呼び出しIDと等しいです: 5494204CSeq: 4524323 接触を参照してください: <一口: 3402934234@conf.example.com 、gt;、;isfocusが以下を許容する 招待、ACK、取り消してください、そして、オプション(さようなら)が参照される、登録、通知してください。受け入れてください: アプリケーション/sdp、sipfrag Referメッセージ/To: <一口: 3402934234@conf.example.com 、gt;、支持される: gruuに接合して、Content-長さを置き換えます: 0
F11 INVITE sip:3402934234@conf.example.com SIP/2.0
Via: SIP/2.0/UDP client.biloxi.com;branch=z9hG4bKh3887
Max-Forwards: 70
To: <sip:3402934234@conf.example.com>
From: Bob <sip:bob@biloxi.example.com>;tag=32411
Call-ID: 5d4324fa84b4c76e66710
CSeq: 764 INVITE
Contact: <sip:bob@client.biloxi.example.com>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
SUBSCRIBE, NOTIFY
Allow-Events: dialog
Accept: application/sdp, message/sipfrag
Supported: replaces, join
Content-Type: application/sdp
Content-Length: ...
F11 INVITE一口: 3402934234@conf.example.com SIP/2.0Via: 一口/2.0/UDP client.biloxi.com; ブランチは前方へz9hG4bKh3887マックスと等しいです: 70 To: <一口: 3402934234@conf.example.com 、gt;、From: ボブ<一口: bob@biloxi.example.com 、gt;、; タグは32411呼び出しIDと等しいです: 5d4324fa84b4c76e66710 CSeq: 764 接触を招いてください: <一口: bob@client.biloxi.example.com 、gt;、許容します: 登録、招待、ACK、取り消してください、そして、オプション(さようなら)を参照して、出来事を許容して通知してください: 対話Accept: アプリケーション/sdp、メッセージ/sipfrag Supported: 取り替え、コンテントタイプを接合してください: sdp Contentアプリケーション/長さ: ...
Johnston & Levin Best Current Practice [Page 25] RFC 4579 SIP CC Conferencing for UAs August 2006
ジョンストンとレヴィン最も良い現在の習慣[25ページ]RFC4579一口は2006年8月にUAsのために会議をCCします。
(SDP not shown)
(見せられなかったSDP)
5.8. Join Header Field: Dialing in to a Conference Using a (3rd Party)
Dialog Identifier
5.8. ヘッダーフィールドを接合してください: (第3パーティ)対話識別子を使用することでコンファレンスに直通電話にかけます。
Under some circumstances, a participant wanting to join a conference may only know a dialog identifier of one of the legs of the conference. The information may have been learned using the dialog package [18] or some non-SIP means to retrieve this information from another conference participant.
いくつかの状況で、会議に参加したがっている関係者は会議の行程の1つに関する対話識別子を知っているだけであるかもしれません。 情報が対話パッケージ[18]を使用することで学術的であったかもしれませんか、またはいくらかの非SIPが、別の会議の参加者からのこの情報を検索することを意味します。
A UA can request to be added to a conference by sending a request to the focus containing a Join [7] header field containing a dialog ID of one leg of the conference (a dialog between another participant and the focus).
UAは、1の対話IDを含むJoin[7]ヘッダーフィールドを含む焦点に要求を送ることによって会議に追加されるために、急いで歩くよう会議(別の関係者と焦点の間の対話)を要求できます。
There are other scenarios in which a UA can use the Join header for certain conferencing call control scenarios. See [7] for further examples and details.
UAが、ある会議呼び出しコントロールシナリオにJoinヘッダーを使用できる他のシナリオがあります。 さらなる例と詳細のための[7]を見てください。
An example is shown in Figure 8. It is assumed that Alice is a participant of the conference. The dialog identifier between Alice and the focus is abbreviated as A-F and is known by Bob. Bob requests to be added to the conference by sending an INVITE message F1 to the focus containing a Join header that contains the dialog identifier A-F. Bob is added into the conference by the focus.
例は図8に示されます。 アリスが会議の関係者であると思われます。 アリスと焦点の間の対話識別子は、A-Fが簡略化されていて、ボブによって知られています。 Joinヘッダーを含む焦点への対話識別子を含むINVITEメッセージF1にA-Fを送ることによって会議に追加されるというボブの要求。 ボブは焦点によって会議に追加されます。
Johnston & Levin Best Current Practice [Page 26] RFC 4579 SIP CC Conferencing for UAs August 2006
ジョンストンとレヴィン最も良い現在の習慣[26ページ]RFC4579一口は2006年8月にUAsのために会議をCCします。
Alice Focus Bob Carol
| | | |
|<==================>| | |
| | | |
| Bob requests to be added to the conference. |
| | | |
| | INVITE Join:A-F F1| |
| |<-------------------| |
| | 180 Ringing F2 | |
| |------------------->| |
| | 200 OK Contact:Conf-ID;isfocus F3 |
| |------------------->| |
| | ACK F4 | |
| |<-------------------| |
| | RTP | |
| NOTIFY F5 |<==================>| |
|<-------------------| SUBSCRIBE sip:Conf-ID F6 |
| 200 OK F7 |<-------------------| |
|------------------->| 200 OK F8 | |
| |------------------->| |
| | NOTIFY F9 | |
| |------------------->| |
| | 200 OK F10 | |
| |<-------------------| |
アリス・焦点ボブ・キャロル| | | | |<=========>|、|、|、|、|、|、|、| 会議に追加されるというボブの要求。 | | | | | | | 招待は: A-F F1を接合します。| | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、| 180 F2を鳴らすこと。| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| 200OK接触: Conf-ID; isfocus F3| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| ACK F4| | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、| RTP| | | F5に通知してください。|<=========>|、| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| 一口: Conf-ID F6を申し込んでください。| | 200 OK F7| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| 200 OK F8| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| F9に通知してください。| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| 200 OK F10| | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|
Figure 8. Adding a Participant to an Existing Conference using Join.
エイト環。 関係者を加えて、既存のコンファレンス使用に接合してください。
F1 INVITE sip:3402934234@conf.example.com SIP/2.0
Via: SIP/2.0/UDP client.biloxi.com;branch=z9hG4bKh3832
Max-Forwards: 70
To: <sip:3402934234@conf.example.com>
From: Bob <sip:bob@biloxi.example.com>;tag=32411
Call-ID: d432fa84b4c76e66710
CSeq: 8 INVITE
Contact: <sip:bob@client.biloxi.example.com>
Join: 3434034-293553453;to-tag=fdj3l34;from-tag=12f331
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
SUBSCRIBE, NOTIFY
Allow-Events: dialog
Accept: application/sdp, message/sipfrag
Supported: replaces, join
Content-Type: application/sdp
Content-Length: ...
F1 INVITE一口: 3402934234@conf.example.com SIP/2.0Via: 一口/2.0/UDP client.biloxi.com; ブランチは前方へz9hG4bKh3832マックスと等しいです: 70 To: <一口: 3402934234@conf.example.com 、gt;、From: ボブ<一口: bob@biloxi.example.com 、gt;、; タグは32411呼び出しIDと等しいです: d432fa84b4c76e66710 CSeq: 8 接触を招いてください: <一口: bob@client.biloxi.example.com 、gt;、接合します: 3434034-293553453; タグ=fdj3l34に; タグ=12f331から以下を許容してください。 登録、招待、ACK、取り消してください、そして、オプション(さようなら)を参照して、出来事を許容して通知してください: 対話Accept: アプリケーション/sdp、メッセージ/sipfrag Supported: 取り替え、コンテントタイプを接合してください: sdp Contentアプリケーション/長さ: ...
(SDP not shown)
(見せられなかったSDP)
Johnston & Levin Best Current Practice [Page 27] RFC 4579 SIP CC Conferencing for UAs August 2006
ジョンストンとレヴィン最も良い現在の習慣[27ページ]RFC4579一口は2006年8月にUAsのために会議をCCします。
5.9. Replaces Header Field: Switching User Agents within a Conference
5.9. ヘッダーフィールドを取り替えます: コンファレンスの中でユーザエージェントを切り換えます。
Participants in a conference may want to change the user agent (i.e., the endpoint or the device) with which they participate in the conference. This could be done by simply sending a BYE from one user agent to leave the conference and an INVITE from the other user agent to rejoin. However, the SIP Replaces [6] primitive is perfectly suited to this operation.
会議の関係者は彼らと会議に参加するユーザエージェント(すなわち、終点か装置)を変えたがっているかもしれません。 もう片方のユーザエージェントからの会議とINVITEが再び加わるのを残すために1人のユーザエージェントからBYEを単に送ることによって、これができるでしょう。 しかしながら、SIP Replaces[6]基関数はこの操作に完全に合っています。
An example is shown in Figure 9. It is assumed that Alice is a participant of the conference using user agent #1. The dialog identifier between Alice's user agent #1 and the focus is abbreviated as A-F. Alice switches to user agent #2 and sends an INVITE message F1 to the focus containing a Replaces header that contains the dialog identifier A-F. Note that this dialog identifier could be learned through some non-SIP mechanism, or by use of SUBSCRIBE/NOTIFY and the dialog event package [18]. Alice's user agent #2 is added into the conference by the focus. The focus sends a BYE to user agent #1. User agent #1 then automatically terminates the subscription by sending a SUBSCRIBE with Expires:0 to terminate the subscription. Note that the participant list (roster) has not necessarily changed during this scenario, unless detailed information about Alice user agents (i.e. endpoints) is included in the conference state notifications. For a full discussion of conference package notifications, refer to [9].
例は図9に示されます。 アリスがユーザエージェント#1を使用する会議の関係者であると思われます。 アリスのユーザエージェント#1と焦点の間の対話識別子はA-Fが簡略化されています。 アリスは、ユーザエージェント#2に切り替わって、Replacesヘッダーを含む焦点への対話識別子を含むINVITEメッセージF1にA-Fを送ります。 この対話識別子が何らかの非SIPメカニズムか、登録、/NOTIFYの使用と対話イベントパッケージ[18]によって学習されるかもしれないことに注意してください。 アリスのユーザエージェント#2は焦点によって会議に追加されます。 焦点はユーザエージェント#1にBYEを送ります。 そして、ユーザエージェント#1は、購読を終えるためにExpires: 0と共に登録を送ることによって、自動的に購読を終えます。 関与しているリスト(当直表)が必ずこのシナリオの間変化するというわけではなかったことに注意してください、アリスユーザエージェント(すなわち、終点)の詳細な情報が会議州の通知に含まれていない場合。 会議パッケージ通知の十分な議論について、[9]を参照してください。
Johnston & Levin Best Current Practice [Page 28] RFC 4579 SIP CC Conferencing for UAs August 2006
ジョンストンとレヴィン最も良い現在の習慣[28ページ]RFC4579一口は2006年8月にUAsのために会議をCCします。
Alice UA#1 Focus Alice UA#2 Carol
| | | |
|<==================>| | |
| | | |
| Alice switches user agents during the conference. |
| | | |
| | INVITE sip:Conf-ID Replaces:A-F F1 |
| |<-------------------| |
| | 200 OK Contact:Conf-ID;isfocus F2 |
| |------------------->| |
| | ACK F3 | |
| |<-------------------| |
| | RTP | |
| |<==================>| |
| BYE F4 | | |
|<-------------------| | |
| 200 OK F5 | | |
|------------------->| | |
| SUBSCRIBE Expires:0 F6 | |
|------------------->| | |
| 200 OK F7 | | |
|<-------------------| | |
| NOTIFY Subscription-State:terminated F8 | |
|<-------------------| | |
| 200 OK F9 | | |
|------------------->| | |
| | SUBSCRIBE sip:Conf-ID F10 |
| |<-------------------| |
| | 200 OK F11 | |
| |------------------->| |
| | NOTIFY F12 | |
| |------------------->| |
| | 200 OK F13 | |
| |<-------------------| |
アリス・UA#1つの焦点アリスUA#2キャロル| | | | |<=========>|、|、|、|、|、|、|、| アリスは会議の間、ユーザエージェントを切り換えます。 | | | | | | | 一口: Conf-IDが取り替える招待: A-F F1| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、| 200OK接触: Conf-ID; isfocus F2| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| ACK F3| | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、| RTP| | | |<=========>|、|、| さようならF4| | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、| 200 OK F5| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| 登録、: 0F6を吐き出します。| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| 200 OK F7| | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、| 購読州: 終えられたF8に通知してください。| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、| 200 OK F9| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、|、| 一口: Conf-ID F10を申し込んでください。| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、| 200 OK F11| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| F12に通知してください。| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| 200 OK F13| | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|
Figure 9. Switching a User Agent within a Conference.
図9。 コンファレンスの中でユーザエージェントを切り換えます。
5.10. Replaces Header Field: Transferring a Point-to-Point Session into
a Conference
5.10. ヘッダーフィールドを取り替えます: 二地点間セッションをコンファレンスに移します。
This call flow shows how a point-to-point call can be transferred to a conference call involving an external focus.
この呼び出し流動は、どう二地点間呼び出しを電話会議に移すことができるかが外部の焦点にかかわるのを示します。
Alice and Bob have an established session with a dialog identifier A-B. Alice joins the conference with the focus by sending an INVITE to the Conference URI. Alice then sends a REFER request to the focus to send an INVITE request to the other participant. Alice includes an escaped Replaces header field in the URI included in the Refer-To
アリスとボブは対話識別子との確立したセッションを過します。A-B。 コンファレンスURIにINVITEを送ることによって、アリスは焦点との会議に参加します。 そして、アリスは、INVITE要求をもう片方の関係者に送るためにREFER要求を焦点に送ります。 アリスが、URIにおける逃げられたReplacesヘッダーフィールドを含んでいるのを入れる、Refer、-
Johnston & Levin Best Current Practice [Page 29] RFC 4579 SIP CC Conferencing for UAs August 2006
ジョンストンとレヴィン最も良い現在の習慣[29ページ]RFC4579一口は2006年8月にUAsのために会議をCCします。
header field. Bob receives the INVITE from the focus and matches the dialog in the Replaces header field with the dialog with Alice. As a result, Bob accepts the INVITE, joins the conference, and sends a BYE to Alice to tear down their point-to-point dialog.
ヘッダーフィールド。 ボブは、アリスと共に焦点からINVITEを受け取って、Replacesヘッダーフィールドにおける対話に対話に合っています。 その結果、ボブは、それらの二地点間対話を取りこわすためにINVITEを受け入れて、会議に参加して、BYEをアリスに送ります。
Alice Focus Bob Carol
| | | |
| Alice is in a session with Bob | |
|<=======================================>| |
| | | |
| Alice joins the conference | |
| | | |
| INVITE sip:Conf-ID F1 | |
|------------------->| | |
| 200 OK Contact:sip:Conf-ID;isfocus F2 | |
|<-------------------| | |
| ACK F3 | | |
|------------------->| | |
| SUBSCRIBE F4 | | |
|------------------->| | |
| 200 OK F5 | | |
|<-------------------| | |
| NOTIFY F6 | | |
|<-------------------| | |
| 200 OK F7 | | |
|------------------->| | |
|<==================>| | |
| | | |
| Alice asks focus to REFER Bob into conference |
| | | |
| REFER sip:Conf-ID Refer-To:Bob?Replaces=A-B F8 |
|------------------->| | |
| 202 Accepted F9 | | |
|<-------------------| | |
| NOTIFY (Trying) F10| | |
|<-------------------| | |
| 200 OK F11 | | |
|------------------->| | |
| | | |
| Focus invites Bob to the conference |
| | | |
| | INVITE sip:Conf-ID Replaces:A-B F12 |
| |------------------->| |
| | 200 OK F13 | |
| |<-------------------| |
| | ACK F14 | |
| |------------------->| |
| | RTP | |
アリス・焦点ボブ・キャロル| | | | | ボブとのセッションのときに、アリスはいます。| | |<====================>|、|、|、|、|、|、| アリスは会議に参加します。| | | | | | | 一口: Conf-ID F1を招いてください。| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| 200OK接触: ちびちび飲んでください: Conf-ID、isfocus F2| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、| ACK F3| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| F4を申し込んでください。| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| 200 OK F5| | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、| F6に通知してください。| | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、| 200 OK F7| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、| |<=========>|、|、|、|、|、|、|、| アリスは会議へのREFERボブに焦点を招きます。| | | | | | 一口: To:を参照しているConf-IDボブを参照するか、=A-B F8を取り替えます。| |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| 202 受け入れられたF9| | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、| (試みること)のF10に通知してください。| | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、| 200 OK F11| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、|、|、|、|、| 焦点は会議にボブを招待します。| | | | | | | 一口を招待してください: Conf-IDは1B F12である状態で以下を取り替えます。| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| 200 OK F13| | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、| ACK F14| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| RTP| |
Johnston & Levin Best Current Practice [Page 30] RFC 4579 SIP CC Conferencing for UAs August 2006
ジョンストンとレヴィン最も良い現在の習慣[30ページ]RFC4579一口は2006年8月にUAsのために会議をCCします。
| |<==================>| |
| BYE F15 | |
|<----------------------------------------| |
| 200 OK F16 | |
|---------------------------------------->| |
| NOTIFY (200) F17 | | |
|<-------------------| | |
| 200 OK F18 | | |
|------------------->| | |
| NOTIFY F19 | | |
|<-------------------| | |
| 200 OK F20 | | |
|------------------->| | |
| | SUBSCRIBE sip:Conf-ID F21 |
| |<-------------------| |
| | 200 OK F22 | |
| |------------------->| |
| | NOTIFY F23 | |
| |------------------->| |
| | 200 OK F24 | |
| |<-------------------| |
| | | |
| |<=========>|、|、| さようならF15| | |<----------------------------------------| | | 200 OK F16| | |---------------------------------------->| | | (200) F17に通知してください。| | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、| 200 OK F18| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| F19に通知してください。| | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、| 200 OK F20| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、|、| 一口: Conf-ID F21を申し込んでください。| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、| 200 OK F22| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| F23に通知してください。| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| 200 OK F24| | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、|、|、|
Figure 10. Transitioning a Point to Point Session into a Conference.
図10。 コンファレンスへのポイントセッションにポイント移行します。
5.11. REFER with BYE: Requesting That the Focus Remove a Participant
from a Conference
5.11. さようならで、参照してください: 焦点がコンファレンスから関係者を外すよう要求します。
To request that the focus remove a participant from the specified conference, a properly authorized SIP UA (typically the conference owner) can send a REFER to the conference URI with a Refer-To containing the URI of the participant and with the method set to BYE. The requestor does not need to know the dialog information about the dialog between the focus and the participant who will be removed -- the focus knows this information and fills it when it generates the BYE request.
焦点が指定された会議から関係者を外すよう要求するために、適切に認可されたSIP UA(通常会議の所有者)がaがある会議URIにREFERを送ることができる、Refer、-、関係者と方法があるURIを含むのはBYEにセットしました。 要請者は外される焦点と関係者の間の対話の対話情報を知る必要はありません--BYE要求を発生させると、焦点は、この情報を知っていて、それをいっぱいにしています。
An example call flow is shown in Figure 11. It is assumed that Alice and Carol are already participants of the conference and that Alice is authorized to remove members from the conference. Alice sends a REFER to the conference URI with a Refer-To header containing a URI of the form sip:carol@chicago.example.com;method=BYE.
例の呼び出し流動は図11に示されます。 アリスとキャロルが既に会議の関係者であり、アリスが会議からメンバーを免職するのに権限を与えられると思われます。 アリスがaがある会議URIにREFERを送る、Refer、-、フォーム一口のURIを含むヘッダー: carol@chicago.example.com;method はBYEと等しいです。
Johnston & Levin Best Current Practice [Page 31] RFC 4579 SIP CC Conferencing for UAs August 2006
ジョンストンとレヴィン最も良い現在の習慣[31ページ]RFC4579一口は2006年8月にUAsのために会議をCCします。
Alice Focus Bob Carol
| | | |
|<==================>| |
| REFER sip:Conf-ID Refer-To:Carol;method=BYE F1 |
|------------------->| |
| 202 Accepted F2 | |
|<-------------------| |
| NOTIFY (Trying) F3 |
|<-------------------| |
| 200 OK F4 | |
|------------------->| |
| | |
| Focus removes Carol from the conference |
| | |
| | BYE sip:Carol F5 |
| |---------------------------------------->|
| | 200 OK F6 |
| |<----------------------------------------|
| | NOTIFY Subscription-State:terminated F7 |
| |---------------------------------------->|
| | 200 OK F8 |
| |<----------------------------------------|
| NOTIFY (200) F9 | |
|<-------------------| |
| 200 OK F10 | |
|------------------->| |
| NOTIFY F11 | |
|<-------------------| |
| 200 OK F12 | |
|------------------->| |
アリス・焦点ボブ・キャロル| | | | |<=========>|、|、| 一口: To:を参照しているConf-IDキャロルを参照してください; 方法はさようならF1と等しいです。| |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、| 202 受け入れられたF2| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、| (試みること)のF3に通知してください。| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、| 200 OK F4| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、|、|、| 焦点は会議からキャロルを外します。| | | | | | さようなら一口: キャロルF5| | |---------------------------------------->| | | 200 OK F6| | |<----------------------------------------| | | 購読州: 終えられたF7に通知してください。| | |---------------------------------------->| | | 200 OK F8| | |<----------------------------------------| | (200) F9に通知してください。| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、| 200 OK F10| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、| F11に通知してください。| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、| 200 OK F12| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|
Figure 11. Participant Requests That the Focus Remove a Participant
from the Conference.
図11。 関係者は、焦点がコンファレンスから関係者を外すよう要求します。
F1 REFER sip:3402934234@conf.example.com SIP/2.0
Via: SIP/2.0/UDP client.atlanta.example.com;branch=z9hG4bKg4534
Max-Forwards: 70
To: <sip:3402934234@conf.example.com>
From: Alice <sip:alice@atlanta.example.com>;tag=5534562
Call-ID: 849392fklgl43
CSeq: 476 REFER
Contact: <sip:alice@alice.example.com>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
SUBSCRIBE, NOTIFY
Accept: application/sdp, message/sipfrag
Refer-To: <sip:carol@chicago.example.com;method=BYE>
Supported: replaces
Content-Length: 0
F1 REFER一口: 3402934234@conf.example.com SIP/2.0Via: 一口/2.0/UDP client.atlanta.example.com; ブランチは前方へz9hG4bKg4534マックスと等しいです: 70 To: <一口: 3402934234@conf.example.com 、gt;、From: アリス<一口: alice@atlanta.example.com 、gt;、; タグは5534562呼び出しIDと等しいです: 849392fklgl43 CSeq: 476 接触を参照してください: <一口: alice@alice.example.com 、gt;、許容します: 招待、ACK、取り消してください、そして、オプション(さようなら)が参照される、登録、通知してください。受け入れてください: アプリケーション/sdp、sipfrag Referメッセージ/To: <一口: carol@chicago.example.com;method がさようならと等しい、gt;、支持される: Content-長さを置き換えます: 0
Johnston & Levin Best Current Practice [Page 32] RFC 4579 SIP CC Conferencing for UAs August 2006
ジョンストンとレヴィン最も良い現在の習慣[32ページ]RFC4579一口は2006年8月にUAsのために会議をCCします。
F5 BYE sip:carol@client.chicago.example.com SIP/2.0
Via: SIP/2.0/UDP ms5.conf.example.com;branch=z9hG4bK343gf4
Max-Forwards: 70
From: <sip:3402934234@conf.example.com>;tag=5393k2312
To: Carol <sip:carol@chicago.example.com>;tag=32331
Call-ID: d432fa84b4c76e66710
CSeq: 78654 BYE
Content-Length: 0
F5 BYE一口: carol@client.chicago.example.com SIP/2.0Via: 一口/2.0/UDP ms5.conf.example.com; ブランチは前方へz9hG4bK343gf4マックスと等しいです: 70 From: <一口: 3402934234@conf.example.com 、gt;、;=5393k2312To:にタグ付けをしてください キャロル<一口: carol@chicago.example.com 、gt;、; タグは32331呼び出しIDと等しいです: d432fa84b4c76e66710 CSeq: 78654 さようならコンテンツの長さ: 0
5.12. Deleting a Conference
5.12. コンファレンスを削除します。
The default conference policy for conferences created using the Conference Factory URI is that the conference is deleted when the creator departs.
コンファレンスFactory URIを使用することで創設された会議のためのデフォルト会議方針は創造者が出発するとき、会議が削除されるということです。
Figure 12 shows this call flow in which the creator Alice departs causing the conference to be deleted. Note that the order of sending BYEs and final NOTIFYs is not important.
図12は、創造者アリスが出発するこの呼び出し流動で会議を削除するのを示します。 BYEsと最終的なNOTIFYsを送る注文が重要でないことに注意してください。
Johnston & Levin Best Current Practice [Page 33] RFC 4579 SIP CC Conferencing for UAs August 2006
ジョンストンとレヴィン最も良い現在の習慣[33ページ]RFC4579一口は2006年8月にUAsのために会議をCCします。
Alice Focus Bob Carol
| | | |
|<==================>|<==================>| |
| BYE F1 |<=======================================>|
|------------------->| | |
| 200 OK F2 | | |
|<-------------------| | |
| | BYE F3 | |
| |------------------->| |
| | 200 OK F4 | |
| |<-------------------| |
| | BYE F5 |
| |---------------------------------------->|
| | 200 OK F6 |
| |<----------------------------------------|
| NOTIFY Subscription-State:terminated F7 |
|<-------------------| | |
| 200 OK F8 | | |
|------------------->| NOTIFY Subscription-State:terminated F9 |
| |------------------->| |
| | 200 OK F10 | |
| |<-------------------| |
| | NOTIFY Subscription-State:terminated F11|
| |---------------------------------------->|
| | 200 OK F12 |
| |<----------------------------------------|
アリス・焦点ボブ・キャロル| | | | |<=========>|<=========>|、|、| さようならF1|<====================>| |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| 200 OK F2| | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、|、| さようならF3| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| 200 OK F4| | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、| さようならF5| | |---------------------------------------->| | | 200 OK F6| | |<----------------------------------------| | 購読州: 終えられたF7に通知してください。| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、| 200 OK F8| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| 購読州: 終えられたF9に通知してください。| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| 200 OK F10| | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、| 購読州: 終えられたF11に通知してください。| | |---------------------------------------->| | | 200 OK F12| | |<----------------------------------------|
Figure 12. Deleting a Conference.
図12。 コンファレンスを削除します。
5.13. Discovery of URI Properties Using OPTIONS
5.13. オプションを使用するURIの特性の発見
A UA MAY send an OPTIONS request to discover if an opaque URI is a conference URI (resolves to a focus). In addition, the reply to the OPTIONS request can also indicate support for various SIP call control extensions used in this document.
UA MAYは不透明なURIが会議URI(焦点に決議する)であるかどうか発見するというOPTIONS要求を送ります。 また、さらに、OPTIONS要求に関する回答は本書では使用される様々なSIP呼び出しコントロール拡張子のサポートを示すことができます。
Note that the Allow, Accept, Allow-Events, and Supported header fields should be present in an INVITE from a focus or a 200 OK answer from the focus to an INVITE as a part of a normal dialog establishment process.
Allow、Accept、Allow-出来事、およびSupportedヘッダーフィールドが正常な対話設立の過程の一部としてINVITEに焦点からの焦点か200OK答えからINVITEまで存在しているべきであることに注意してください。
An example is shown in Figure 13 where Alice sends an OPTIONS to a URI that resolves to a focus.
例は図13にアリスがどこでそれが焦点に決議するURIにOPTIONSを送るかが示されます。
Johnston & Levin Best Current Practice [Page 34] RFC 4579 SIP CC Conferencing for UAs August 2006
ジョンストンとレヴィン最も良い現在の習慣[34ページ]RFC4579一口は2006年8月にUAsのために会議をCCします。
Alice Focus Bob Carol
| | | |
| OPTIONS sip:Conf-ID F1 | |
|------------------->| | |
| 200 OK Contact:Conf-ID;isfocus F2 | |
|<-------------------| | |
アリス・焦点ボブ・キャロル| | | | | オプション一口: Conf-ID F1| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| 200OK接触: Conf-ID; isfocus F2| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|
Figure 13. Participant Queries Capabilities of URI of a Focus.
図13。 関係者は焦点のURIの能力について質問します。
Following is an example of message detail of message F2 in Figure 13. Based on the response, Alice's UA learns that the URI is a conference URI and that the responding UA is focus that supports a number of SIP call control extensions.
以下に、図13のメッセージF2のメッセージ細部に関する例があります。 応答に基づいて、アリスのUAはURIが会議URIであり、応じているUAが多くのSIP呼び出しコントロール拡張子をサポートする焦点であることを学びます。
The response details are as follows:
応答の詳細は以下の通りです:
F2 SIP/2.0 200 OK
Via: SIP/2.0/UDP pc33.atlanta.example.com;branch=z9hG4bKhjsas87
;received=192.0.2.4
To: <sip:3402934234@conf.example.com>;tag=93810874
From: Alice <sip:alice@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 63104 OPTIONS
Contact: <sip:3402934234@conf.example.com>;isfocus
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
SUBSCRIBE, NOTIFY
Allow-Events: refer, conference
Accept: application/sdp, message/sipfrag
Accept-Language: en
Supported: replaces, join, gruu
Content-Type: application/sdp
Content-Length: ...
以下を通ってF2一口/2.0 200OK 一口/2.0/UDP pc33.atlanta.example.com; ブランチはz9hG4bKhjsas87と等しいです; =192.0.2.4To:を受けます。 <一口: 3402934234@conf.example.com 、gt;、;=93810874From:にタグ付けをしてください アリス<一口: alice@atlanta.example.com 、gt;、; タグは1928301774呼び出しIDと等しいです: a84b4c76e66710 CSeq: 63104のオプションが以下に連絡します。 <一口: 3402934234@conf.example.com 、gt;、;isfocusが以下を許容する 登録、招待、ACK、取り消してください、そして、オプション(さようなら)を参照して、出来事を許容して通知してください: 参照してください、会議Accept: アプリケーション/sdp、sipfrag Acceptメッセージ/言語: アンSupported: 取り替え、接合して、コンテントタイプをgruuする、: sdp Contentアプリケーション/長さ: ...
v=0
o=focus431 2890844563 2890842835 IN IP4 ms5.conf.example.com
s=-
i=Example Conference Hosted by Example.com
u=http://conf.example.com/3402934234
e=3402934234@conf-help.example.com
p=+18882934234
c=IN IP4 ms5.conf.example.com
t=0 0
m=audio 0 RTP/AVP 0 3 5 7
m=video 0 RTP/AVP 31 32
v=0 o=focus431 2890844563 2890842835IN IP4 ms5.conf.example.com s=- iは0 3 5 7mのオーディオ0RTP/AVP=ビデオ0 0 0IN 3402934234@conf-help.example.com Example.com u= http://conf.example.com/3402934234 e=p=+18882934234c=IP4 ms5.conf.example.com t=m=RTP/AVP31 32で例のコンファレンスHostedと等しいです。
Useful information from each of these headers is detailed in the next sections.
これらのヘッダー各人からの役に立つ情報は次のセクションで詳細です。
Johnston & Levin Best Current Practice [Page 35] RFC 4579 SIP CC Conferencing for UAs August 2006
ジョンストンとレヴィン最も良い現在の習慣[35ページ]RFC4579一口は2006年8月にUAsのために会議をCCします。
Allow. The support of methods such as REFER, SUBSCRIBE, and NOTIFY indicates that the user agent supports call control and SIP events.
許容します。 REFERなどの方法のサポート、登録、NOTIFYはユーザエージェントが呼び出しコントロールとSIP出来事を支持するのを示します。
Accept. The support of bodies such as message/sipfrag [12] indicates support of call control.
受け入れてください。 メッセージ/sipfrag[12]などのボディーのサポートは呼び出しコントロールのサポートを示します。
Allow-Events. Indicates support of event packages such as refer [4] and conference [9].
出来事を許容します。 [4]を参照するようなイベントパッケージと会議[9]のサポートを示します。
Supported. Indicates support of extensions such as replaces, join, and gruu.
支持にされる。 拡大のサポートを示す、取り替えて、接合して、gruu
Contact. The presence of the 'isfocus' feature parameter in the Contact header indicates that the URI is a conference URI and that the UA is a focus.
連絡します。 Contactヘッダーでの'isfocus'特徴パラメタの存在はURIが会議URIであり、UAが焦点であることを示します。
6. Security Considerations
6. セキュリティ問題
This specification defines the interaction between a focus UA and a participant UA in a conferencing application. As a result, the security considerations and mechanisms defined in RFC 3261 [2] apply. However, there are some aspects unique to conferencing that will be discussed here.
この仕様は会議アプリケーションで焦点UAと関与しているUAとの相互作用を定義します。 その結果、RFC3261[2]で定義されたセキュリティ問題とメカニズムは適用されます。 しかしながら、ここで議論する会議にユニークないくつかの局面があります。
A conference often involves the use of substantial network bandwidth and computing resources. As a result, authentication is even more important than in a simple peer-to-peer session. As discussed in the conferencing framework [8], conferences often have policy related to conferencing resources. A focus SHOULD authenticate participants before joining them to a conference and allowing utilization of conferencing resources. Different policies can be applied by a focus to different participants based on the result of authentication.
会議はしばしばかなりのネットワーク回線容量とコンピューティング資源の使用にかかわります。 その結果、認証は簡単なピアツーピアセッションよりさらに重要です。 会議枠組み[8]で議論するように、会議は方針をしばしば会議リソースに関連させます。 SHOULDが彼らを会議に接合して、会議リソースの利用を許しながら関係者を認証する焦点。 焦点は認証の結果に基づく異なった関係者に異なった方針を適用できます。
A participant will be interacting with a number of other participants through the focus. As a result, a participant should authenticate the focus and be sure that the focus used for the conference is trusted. Normal SIP authentication mechanisms are suitable for participant and focus authentication, such as SIP Digest utilizing a shared secret, or certificates, or a secured SIP identity mechanism. In addition, a focus SHOULD support Secure SIP connections so that hop-by-hop mutual authentication and confidentiality provided by TLS can be achieved.
関係者は焦点を通って多くの他の関係者と対話するでしょう。 その結果、関係者は、焦点を認証して、会議に使用される焦点が信じられるのを確信しているべきです。 正常なSIP認証機構は関係者と焦点認証に適しています、共有秘密キー、または証明書を利用するSIP Digest、または安全にされたSIPアイデンティティメカニズムなどのように。 添加、SHOULDが支持する焦点では、あまりにそんなにホップごとの互いの認証と秘密性がTLSで提供したSecure SIP接続を達成できます。
In the SIP dialog between them, a focus utilizes the 'isfocus' feature tag to indicate that the UA is acting as a focus. As such, the SIP header fields such as Contact SHOULD have end to end integrity. A participant and focus SHOULD support an end-to-end integrity mechanism such as S/MIME.
それらの間のSIP対話では、焦点は、UAが焦点として機能しているのを示すのに'isfocus'特徴タグを利用します。 そういうものとして、Contact SHOULDなどのヘッダーフィールドにはあるSIPは、保全を終わらせるために終わります。 関係者と焦点SHOULDはS/MIMEなどの終わりから終わりへの保全メカニズムをサポートします。
Johnston & Levin Best Current Practice [Page 36] RFC 4579 SIP CC Conferencing for UAs August 2006
ジョンストンとレヴィン最も良い現在の習慣[36ページ]RFC4579一口は2006年8月にUAsのために会議をCCします。
Once a participant has learned that the other UA is a focus, SIP call control operations (such as REFER) can be implemented, or a subscription to the conference package of the focus might be attempted. The security considerations described in RFC 3515 [4] apply to any REFER call control operations. A focus and participant will apply policy to determine which call control operations are allowed.
関係者が、もう片方のUAが焦点であることをいったん学ぶと、SIP呼び出し制御機能(REFERなどの)を実行できますか、または焦点の会議パッケージの購読は試みられるかもしれません。 RFC3515[4]で説明されたセキュリティ問題はどんなREFER呼び出し制御機能にも適用されます。 焦点と関係者は、どの呼び出し制御機能が許容されているかを決定するために方針を適用するでしょう。
A focus accepting subscriptions to the conference package must follow the security considerations in RFC 4575 [9]. Since notifications can carry sensitive information, the subscriptions should be authenticated and the notifications delivered with confidentiality and integrity protection. Since a participant is not able to authenticate other participants directly, a participant must rely on the focus to perform this authentication.
会議パッケージの購読を受け入れる焦点はRFC4575[9]でセキュリティ問題に従わなければなりません。 通知が機密情報を運ぶことができるので、購読は認証されるべきでした、そして、通知は秘密性と保全保護と共に配送されました。 関係者が直接他の関係者を認証できないので、関係者はこの認証を実行するために焦点を当てにしなければなりません。
A focus MUST support a participant's request for privacy, either through conference policy or as expressed through the signaling. For example, a participant joining a conference and including a Privacy header field [10] must not have identity information revealed to other participants by the focus. If other signaling protocols are used, privacy signaled through them also must be respected.
焦点はどちらか会議方針かシグナリングを通して言い表されるようにプライバシーを求める関係者の要求を支持しなければなりません。 例えば、会議に参加して、Privacyヘッダーフィールド[10]を含む関係者は焦点でアイデンティティ情報を他の関係者に明らかにさせてはいけません。 他のシグナリングプロトコルが使用されているなら、それらを通して合図されたプライバシーも尊敬しなければなりません。
7. Contributors
7. 貢献者
We would like to thank Rohan Mahy, Jonathan Rosenberg, Roni Even, Petri Koskelainen, Brian Rosen, Paul Kyzivat, Eric Burger, and others in list discussions.
リスト議論でRohanマーイ、ジョナサン・ローゼンバーグ、ロニEven、ペトリKoskelainen、ブライアン・ローゼン、ポールKyzivat、エリックBurger、および他のものに感謝申し上げます。
Thanks to Miguel Garcia for his detailed last-call review and suggestions.
彼の詳細な最後の呼び出しレビューと提案をミゲル・ガルシアをありがとうございます。
Johnston & Levin Best Current Practice [Page 37] RFC 4579 SIP CC Conferencing for UAs August 2006
ジョンストンとレヴィン最も良い現在の習慣[37ページ]RFC4579一口は2006年8月にUAsのために会議をCCします。
8. References
8. 参照
8.1. Normative References
8.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月。
[3] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
[3] ローチ、A.、「セッション開始プロトコル(一口)特定のイベント通知」、RFC3265、2002年6月。
[4] Sparks, R., "The Session Initiation Protocol (SIP) Refer
Method", RFC 3515, April 2003.
[4] スパークス、R.、「セッション開始プロトコル(一口)は方法を参照する」RFC3515、2003年4月。
[5] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating
User Agent Capabilities in the Session Initiation Protocol
(SIP)", RFC 3840, August 2004.
[5] ローゼンバーグ、J.、Schulzrinne、H.、およびP.Kyzivat、「ユーザを示して、セッション開始におけるエージェント能力は(一口)について議定書の中で述べます」、RFC3840、2004年8月。
[6] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation
Protocol (SIP) "Replaces" Header", RFC 3891, September 2004.
[6] マーイ、R.、ビッグズ、B.、およびR.ディーン、RFC3891、「セッション開始プロトコル(一口)はヘッダーを「取り替え」であっ」て、9月は2004です。
[7] Mahy, R. and D. Petrie, "The Session Initiation Protocol (SIP)
"Join" Header", RFC 3911, October 2004.
2004年10月の[7] マーイ、R. and D.ピートリー、「「接合してください」というセッション開始プロトコル(一口)ヘッダー」RFC3911。
[8] Rosenberg, J., "A Framework for Conferencing with the Session
Initiation Protocol (SIP)", RFC 4353, February 2006.
2006年2月の[8] ローゼンバーグ、J.、「セッション開始プロトコル(一口)がある会議のための枠組み」RFC4353。
[9] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session
Initiation Protocol (SIP) Event Package for Conference State",
RFC 4575, August 2006.
[9] ローゼンバーグ、J.、Schulzrinne、H.、およびO.レヴィン、「コンファレンス状態へのセッション開始プロトコル(一口)イベントパッケージ」、RFC4575(2006年8月)。
[10] Peterson, J., "A Privacy Mechanism for the Session Initiation
Protocol (SIP)", RFC 3323, November 2002.
[10] ピーターソン、J.、「セッション開始プロトコル(一口)のためのプライバシーメカニズム」、RFC3323、2002年11月。
8.2. Informative References
8.2. 有益な参照
[11] Campbell, B. and R. Sparks, "Control of Service Context using
SIP Request-URI", RFC 3087, April 2001.
[11] キャンベルとB.とR.スパークス、「一口要求URIを使用するサービス文脈のコントロール」、RFC3087、2001年4月。
[12] Sparks, R., "Internet Media Type message/sipfrag", RFC 3420,
November 2002.
R.、「インターネットメディアTypeメッセージ/sipfrag」、RFC3420 2002年11月の[12]スパーク。
[13] Johnston, A., Donovan, S., Sparks, R., Cunningham, C., and K.
Summers, "Session Initiation Protocol (SIP) Basic Call Flow
Examples", BCP 75, RFC 3665, December 2003.
[13] ジョンストン、A.、ドノヴァン、S.、スパークス、R.、カニンハム、C.、およびK.夏、「セッション開始プロトコル(一口)基本的な呼び出し流れの例」、BCP75、RFC3665、2003年12月。
Johnston & Levin Best Current Practice [Page 38] RFC 4579 SIP CC Conferencing for UAs August 2006
ジョンストンとレヴィン最も良い現在の習慣[38ページ]RFC4579一口は2006年8月にUAsのために会議をCCします。
[14] Levin, O. and R. Even, "High Level Requirements for Tightly
Coupled SIP Conferencing", RFC 4245, November 2005.
[14] レヴィン、O.、およびR.、同等である、「密結合一口会議のための高い平らな要件」、RFC4245、11月2005日
[15] Mahy, R., "A Call Control and Multi-party usage framework for
the Session Initiation Protocol (SIP)", Work in Progress,
February 2005.
[15] マーイ、R.、「Session Initiationプロトコル(SIP)のためのCall ControlとMulti-パーティー用法枠組み」、Progress(2005年2月)のWork。
[16] Rosenberg, J., "Obtaining and Using Globally Routable User
Agent (UA) URIs (GRUU) in the Session Initiation Protocol
(SIP)", Work in Progress, February 2005.
[16] ローゼンバーグ、J.、「セッション開始プロトコル(一口)にRoutableユーザエージェント(UA)URI(GRUU)をグローバルに得て、使用すること」は進行中(2005年2月)で働いています。
[17] Sparks, R., Johnston, A., and D. Petrie, "Session Initiation
Protocol Call Control - Transfer", Work in Progress, April
2005.
[17] R.、ジョンストン、A.、D.ピートリー、「セッション開始プロトコル呼び出しコントロール--移す」というスパークは、進歩、2005年4月に働いています。
[18] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE-
Initiated Dialog Event Package for the Session Initiation
Protocol (SIP)", RFC 4235, November 2005.
[18] ローゼンバーグ、J.、Schulzrinne、H.、およびR.マーイ、「招待はセッション開始プロトコル(一口)のために対話イベントパッケージを開始しました」、RFC4235、2005年11月。
Johnston & Levin Best Current Practice [Page 39] RFC 4579 SIP CC Conferencing for UAs August 2006
ジョンストンとレヴィン最も良い現在の習慣[39ページ]RFC4579一口は2006年8月にUAsのために会議をCCします。
Appendix A: Creating a Conference by a Conference-Unaware UA
付録A: コンファレンス気づかないUAはコンファレンスを作成します。
This section discusses how a human user operating a conference- unaware UA can create and add participants to a conference. This method is described as an appendix since it is NOT RECOMMENDED. The scenarios involving creating a conference using ad-hoc or manual means are recommended over this scenario. This scenario is included, however, for completeness.
このセクションは会議の気づかないUAを操作している人間のユーザがどう関係者を会議に創造して、追加できるかを論じます。 この方法は、それがNOT RECOMMENDEDであるので、付録として記述されています。 臨時の、または、手動の手段を使用することで会議を創設することを伴うシナリオはこのシナリオの上でお勧めです。 しかしながら、このシナリオは完全性のために含まれています。
A user (human) would choose a conference URI according to system rules and insert it into the Request-URI of the INVITE. This same URI is echoed by a focus adhering to certain addressing conventions (discussed below) in the Contact header by the focus. Additional participants could be added by non-SIP means (publication of the chosen conference URI using web pages, email, IM, etc.). Alternatively, the conference-unaware UA could then add other participants to the conference using SIP call control by establishing a session with them, then transferring [17] them to the conference URI. Note that in this scenario only the user (human) is aware of the conferencing application, and the conference-unaware UA only need support RFC 3261 [2] and optionally call transfer.
ユーザ(人間)は、システム規則に従って会議URIを選んで、INVITEのRequest-URIにそれを挿入するでしょう。 この同じURIは焦点でContactヘッダーで、あるアドレシングコンベンションを固く守る(以下では、議論します)焦点によって反響されます。 非SIP手段(ウェブページ、メール、IMなどを使用する選ばれた会議URIの公表)で追加関係者を加えることができるでしょう。 あるいはまた、次に、会議気づかないUAは、SIPを使用する会議への他の関係者が彼らとのセッションを確立することでコントロールを呼ぶと言い足すことができました、次に、[17] 彼らを会議URIに移して。 このシナリオだけでは、ユーザ(人間)が会議アプリケーションを意識していることに注意してください、会議気づかないUAは、任意に転送と呼びますサポートRFC3261[2]が必要があるだけであり。
Making this work does impose certain addressing conventions on a system. As a service/implementation choice, a system could allow the creator of the conference to choose the user portion of the conference URI. However, this requires the URI format to be agreed upon between a user and the system.
この仕事をすると、あるアドレシングコンベンションはシステムにつけ込みます。 サービス/実現選択として、システムで、会議の創造者は会議URIのユーザ部分を選ぶことができました。 しかしながら、これは、URI書式がユーザとシステムの間で同意されるのを必要とします。
For example, a service provider might reserve the domain conf.example.com for all conference URIs. Any URI in the domain of conf.example.com would resolve to the focus. The focus could be configured to interpret an unknown user part in the conf.example.com domain as a request for a conference to be created with the conference URI as the Request-URI. For example, an INVITE sent with a Request-URI of sip:k32934208ds72@conf.example.com could be routed to the focus that would then create the conference. This conference URI should be registered by the newly created focus to become routable as a conference URI within the conf.example.com domain. The returned Contact would look as follows:
例えば、サービスプロバイダーはすべての会議URIのためにドメインconf.example.comを予約するかもしれません。 conf.example.comのドメインのどんなURIも焦点まで決議するでしょう。 会議がRequest-URIとして会議URIで創設されるという要求としてconf.example.comドメインで未知のユーザ部分を解釈するために焦点を構成できました。 例えば、INVITEは一口のRequest-URIと共に発信しました: 次に会議を創設する焦点に k32934208ds72@conf.example.com を発送できました。 この会議URIは新たに作成された焦点によって登録されて、会議URIとしてconf.example.comドメインの中で発送可能になるべきです。 返されたContactは以下の通りに見えるでしょう:
Contact: <sip:k32934208ds72@conf.example.com>;isfocus
接触: <一口: k32934208ds72@conf.example.com 、gt;、;、isfocus
Johnston & Levin Best Current Practice [Page 40] RFC 4579 SIP CC Conferencing for UAs August 2006
ジョンストンとレヴィン最も良い現在の習慣[40ページ]RFC4579一口は2006年8月にUAsのために会議をCCします。
Note, however, that this approach relies on conventions adopted between the user (human) and the focus. Also, the approach is not robust against collisions in the conference names. If a second user wishing to create a new conference happened to choose the same user part as an existing conference, the result would be that the second user would be added into the existing conference instead of creating a new one.
しかしながら、このアプローチがユーザ(人間)と焦点の間に採用されたコンベンションを当てにすることに注意してください。 また、アプローチも会議名における衝突に対して体力を要しません。 新しい会議を創設したがっている2番目のユーザがたまたま既存の会議と同じユーザ部分を選ぶなら、結果は2番目のユーザが新しいものを作成することの代わりに既存の会議に追加されるだろうということでしょうに。
As a result, methods of conference creation in which the conference URI is an opaque URI generated by the focus are preferred.
その結果、会議URIが焦点で発生する不透明なURIである会議創造の方法は好まれます。
An example call flow is shown in Figure 14. The participant Alice creates the conference URI (using some convention agreed to with the focus domain) and sends an INVITE to that URI which creates the focus. The focus creates the conference and returns the same conference URI in the 200 OK answer to the INVITE (which is ignored by the conference-unaware UA).
例の呼び出し流動は図14に示されます。 関与しているアリスは、会議URI(いくつかを使用しますコンベンションが焦点ドメインに同意した)を作成して、焦点を作成するそのURIにINVITEを送ります。 焦点は、INVITE(会議気づかないUAによって無視される)の200OK答えで会議を創設して、同じ会議URIを返します。
Alice Focus Bob Carol
| | | |
| Alice creates the conference and chooses the conference URI. |
| | | |
| INVITE sip:Conf-ID F1 | |
|------------------->| | |
| 180 Ringing F2 | | |
|<-------------------| | |
| 200 OK Contact:Conf-ID;isfocus F3 | |
|<-------------------| | |
| ACK F4 | | |
|------------------->| | |
| RTP | | |
|<==================>| | |
アリス・焦点ボブ・キャロル| | | | | アリスは、会議を創設して、会議URIを選びます。 | | | | | | 一口: Conf-ID F1を招いてください。| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| 180 F2を鳴らすこと。| | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、| 200OK接触: Conf-ID; isfocus F3| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、| ACK F4| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| RTP| | | |<=========>|、|、|
Figure 14. Not Recommended: Conferencing Unaware Participant
Creates a Conference
図14。 お勧めでない: 会議の気づかない関係者はコンファレンスを作成します。
Johnston & Levin Best Current Practice [Page 41] RFC 4579 SIP CC Conferencing for UAs August 2006
ジョンストンとレヴィン最も良い現在の習慣[41ページ]RFC4579一口は2006年8月にUAsのために会議をCCします。
Authors' Addresses
作者のアドレス
Alan Johnston Avaya St. Louis, MO 63102
アラン・ジョンストン・Avayaセントルイス、MO 63102
EMail: alan@sipstation.com
メール: alan@sipstation.com
Orit Levin Microsoft Corporation One Microsoft Way Redmond, WA 98052
Oritレヴィンマイクロソフト社1マイクロソフト道、レッドモンド、ワシントン 98052
EMail: oritl@microsoft.com
メール: oritl@microsoft.com
Johnston & Levin Best Current Practice [Page 42] RFC 4579 SIP CC Conferencing for UAs August 2006
ジョンストンとレヴィン最も良い現在の習慣[42ページ]RFC4579一口は2006年8月にUAsのために会議をCCします。
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)によって提供されます。
Johnston & Levin Best Current Practice [Page 43]
ジョンストンとレヴィンBest現在の習慣[43ページ]
一覧
スポンサーリンク
