[要約] RFC 4579は、SIPユーザーエージェントの会議に関する情報を提供するための規格です。その目的は、SIPユーザーエージェント間での会議制御を可能にすることです。
Network Working Group A. Johnston
Request for Comments: 4579 Avaya
BCP: 119 O. Levin
Category: Best Current Practice Microsoft Corporation
August 2006
Session Initiation Protocol (SIP) Call Control - Conferencing for User Agents
セッション開始プロトコル（SIP）コールコントロール - ユーザーエージェントの会議
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.
このドキュメントは、インターネットコミュニティのインターネットの最良のプラクティスを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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.
この仕様では、セッション開始プロトコル（SIP）の会議コールコントロール機能を定義します。このドキュメントは、会議の要件とフレームワークドキュメントに基づいて、厳密に結合したSIP会議がどのように機能するかを定義します。このアプローチは、異なるユーザーエージェント（UA）タイプの観点から調査されています：Conference-Unaware、Conference-Aware、Focus UAS。会議での均一なリソース識別子（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
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
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メカニズムと慣習を使用して、定義された機能を備えた簡単な会議を実施できます。他の多くの高度な機能は、追加の手段を使用して実装できますが、このドキュメントの範囲内ではありません。
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:
コールコントロールおよびダイアログ操作アプローチは、Multiparty Frameworkドキュメント[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.
RFC 3087 [11]で説明されているように、不透明なURIの使用とURI内のコールコントロールコンテキスト情報を（サービス関連のヘッダーフィールドの使用とは対照的に）通信する機能は、このアプローチの基本です。
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」機能パラメーターの使用法を定義します。
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].
このドキュメントでは、キーワードが「必須」、「必須」、「必須」、「shall」、「shall "、" low "of" bould "、" becommented "、"、 "、"、 "optional"RFC 2119で説明されているように解釈され、準拠した実装の要件レベルを示します[1]。
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 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.
焦点は、会議パッケージRFC 4575 [9]をサポートし、そのパッケージの紹介者として動作し、リクエストと応答のAllow-Ieventsヘッダーフィールドでのサポートを示す必要があります。焦点には、セッション情報、URI、電子メールアドレス、および電話番号SDPフィールドに住むことにより、通常のSIPシグナル伝達の一部として送信されたセッション説明プロトコル（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つのエンドポイント間に確立されたセッションが集中会議に移行できる高度な機能をサポートするために、焦点は交換ヘッダーフィールドをサポートする必要があります[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.
任意のタイプとサイズの会議を同時にホストすることが主なタスクである専用の会議サーバーは、任意の数のアドホック会議を作成するために会議工場URI（次のセクションで定義されている）を割り当てて公開することができます（そしてその後、彼らの焦点は）SIPコールコントロール手段の使用。
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.
フレームワークによると、会議を作成するには多くの方法があります。会議サーバーの実装は、これらの方法（インタラクティブな音声応答（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コールコントロール手段を使用して、任意の数のアドホック会議（およびその後のフォーカス）を自動的に作成するために、グローバルにルーティング可能な会議工場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への呼びかけを確立するための成功した試みは、新しい会議とその焦点の自動作成につながるでしょう。その結果、会議工場のURIと新しく作成されたフォーカスURIが異なる物理デバイスに解決する可能性があることに注意してください。
A scenario showing the use of the conference factory URI is shown in Section 5.4.
会議工場URIの使用を示すシナリオは、セクション5.4に示されています。
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には、RFC 3261 [2]のみをサポートする必要があります。Conference-Unaware UAのコールフローは、SIPコールフロードキュメント[13]のものと同一であるため、このドキュメントでは一般的には表示されません。
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.
コンタクトヘッダーフィールドに「ISFOCUS」機能タグが存在すると、標準的なSIPの動作に従って、未知のヘッダーパラメーターとして扱われ、無視されるため、フォーカスとカンファレンスのない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.
会議を受けたユーザーエージェントは、RFC 3261 [2]のサポートに加えて、会議参加者としてこのドキュメントで定義されたSIP会議のコールコントロールコンベンションをサポートします。会議が認識しているUAは、RFC 3261のセクション8.1.3.4に記載されているようなSIPリダイレクトを処理できる必要があります。
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は、[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.
カンファレンス認識UAは、「isFocus」パラメーターがダイアログのリモートターゲットURIにある場合、およびカンファレンスパッケージがAllow-Ieventsヘッダーフィールドのフォーカスによってリストされている場合、会議パッケージを購読する必要があります。会議パッケージの購読は、招待状が開始したダイアログの外に送信する必要があります。Byeを使用した招待ダイアログの終了は、サブスクライブダイアログを必ずしも終了するわけではありません。
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は、SIPヘッダーフィールドとSDPフィールドから得られた会議に関する情報をフォーカスから提供する場合があります。
A conference-aware UA SHOULD render to the user any information about the conference obtained from the SIP conference package.
カンファレンスを認識しているUAは、SIP会議パッケージから得られた会議に関する情報をユーザーに提供する必要があります。
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拡張と慣習の開発に関する主な設計ガイドラインは、拡張の最小数を定義し、Conference-Unaware SIP UAとのシームレスな後方互換性を持つことです。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.
採用されたアプローチは、機能パラメーター「isFocus」を使用して、SIPダイアログが会議に属していることを表現することです。UAの特性と機能を記述するための接触ヘッダーフィールドでの特徴パラメーターの使用は、ユーザーエージェント機能ドキュメント[5]で説明されています。
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.
セッションの確立では、フォーカスがフォーカスであるという事実を隠したい場合を除き、コンタクトヘッダーフィールドに「ISFOCUS」機能パラメーターを含める必要があります。参加者にとって、機能パラメーターはダイアログのリモートターゲットURIに関連付けられます。結果のダイアログは、コンタクトヘッダーフィールドのURIによって特定された会議に属し、このドキュメントで定義されているコールコントロールコンベンションを適用できることを、会議に意識したUAへの兆候です。
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（GRUU）（[16]で定義）を使用して、グローバルにルーティング可能なユーザーエージェントURIを使用して会議URIで適切に構築できます。
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で実装でき、アクティブなダイアログ内またはダイアログ外のいずれかを実行できます。フォーカスには、フォーカスがフォーカスであるという事実を隠したい場合を除き、オプションに対する200 OK応答の「isFocus」機能パラメーターを含める必要があります。
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会議のプリミティブが、異なる会議機能を持ち、異なるアプリケーションを実装するユーザーエージェントが使用することです。
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がダイヤルインする会議の最初の参加者である場合、この招待が焦点、したがって会議をアクティブにする可能性があります。ただし、会議の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セットの招待状を会議URIに送信します。焦点には、招待に対する200 OK応答のコンタクトヘッダーフィールドに「isFocus」機能パラメーターを含める必要があります。
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 |
| |<----------------------------------------|
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: ...
(SDP not shown)
（SDPが表示されていません）
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: ...
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
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
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
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>
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.
参加者を会議に直接追加するには、会議URIと「ISFOCUS」機能パラメーターにコンタクトヘッダーフィールドを含む参加者に招待を送信する必要があります。
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の観点から）ポイントツーポイントセッションとして扱うことに注意してください。これは、標準のRFC 3261 [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に示します。アリスはすでに会議の参加者であると想定されています。この焦点は、招待を送ることにより、キャロルを会議に招待します。セッションが確立された後、キャロルは会議URIを購読します。キャロルの購読（F5）とアリスへの通知（F9）に依存していないことに注意することが重要です - それらは非同期的かつ独立して発生します。
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 | |
|------------------->| |
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: ...
<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>
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: ...
<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>
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.
このセクションでは、ユーザーがConference Serverアプリケーションに招待状を送信します。システムが会議を作成する前にユーザーからの追加の入力を必要とするため、アプリケーション（IVRシステムやWebページなど）が実装されます。通常のダイアログが確立された後、追加情報が受信され、その焦点とともに会議が作成されます。UAは焦点を当てたダイアログにあるため、フォーカスは「ISFOCUS」機能パラメーターと連絡を取っている会議URIを使用してユーザーを再誘導します。
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の初期のダイアログの議論については、RFC 3261 [2]を参照）。これは、会議アプリケーションによって送信された183のセッション進行状況応答によって達成できます。会議が作成された後、カンファレンスURIは200 OKの連絡先に返されます。
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に示します。この例では、アリスはアリスが会議申請に招待を送信したときにトリガーされる会議アプリケーションを使用しています。この例では、conf-appは会議アプリケーションURIを表すために使用されます。Aliceの会議が認識しているUAは、「ISFOCUS」機能パラメーターから会議の存在を学び、会議パッケージに登録して、会議状態の通知を受け取ります。
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 | | |
|------------------->| | |
Figure 3. A Participant Creates a Conference Using an Application.
図3.参加者は、アプリケーションを使用して会議を作成します。
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で定義されている）は、この例で会議を自動的に作成するために使用されます。これは、人間の介入が必要ないという点で、以前のシナリオとは異なります。オートマトンは会議を作成して参加者を追加できます。会議はスケジュールまたは予約する必要はなく、「オンザフライ」で作成されるため、「アドホック」会議の作成です。
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、Webページフォームなど）が必要ではないことです。
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エンティティ（会議サーバーなど）は、リクエスト-URIによる既存の会議に参加するリクエストから新しいアドホック会議を作成するリクエストとして、この招待リクエストを区別できます。つまり、両方のリクエストが同じアプリケーションにルーティングする場合がありますが、リクエストされた異なるサービスは、リクエスト自体の異なる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.
すべてのセキュリティおよびポリシーの要件が満たされていると仮定すると、Contact URIがConference URIであるという連絡先とともに新しい会議が作成されます。コンタクトヘッダーフィールドには、この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に示します。Conffactoryは会議工場URIの速記であり、Conf-IDは会議URIの略です。このフローでは、アリスは会議に意識したUAを持ち、会議工場URIに招待を送信することで会議を作成します。会議工場アプリケーションは、会議を作成し、302移動した一時的に応答を使用してアリスをフォーカスにリダイレクトします。通常のRFC 3261 [2]の動作の一部として代理再帰を使用すると、アリスはリダイレクトを見ることはないかもしれませんが、メッセージF5から始まるフォーカスから応答を受信するだけであることに注意してください。メディアセッションが確立されると、アリスは、焦点からの200 OK応答で連絡先を通じて得られた会議URIを購読します。
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 | |
|---------------------------------------->| |
Figure 4. Creation of a Conference Using SIP Ad-Hoc Methods.
図4. SIPアドホックメソッドを使用した会議の作成。
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 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.
焦点が指定された会議に新しい情報リソースを追加するように要求するために、任意のSIP UAは、新しいリソースのURIを含む紹介を含む会議URIへの紹介を送信できます。この紹介はカンファレンスファクトリーURIではなく会議URIに送信されるため、焦点のセマンティクスは会議にリソースを持ち込み、会議参加者に見えるようにすることです。結果として得られるフォーカス手順は、新しいリソースの性質（URIで表現されている）とIMに関する焦点のポリシー、中央対分散リアルタイムメディア処理などの両方に依存しています。
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参加者を追加するためのシナリオは、新しい参加者が紹介コールコントロールをサポートしていなくても機能するため、サポートすることが重要です。リクエスト参加者と焦点のみが紹介および転送コールコントロールをサポートする必要があります。
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.
SIP URIを備えた紹介ヘッダーを含む紹介を受信すると、焦点は、会議URIと「Isfocus」機能パラメーターを備えた連絡先ヘッダーフィールドを含む紹介SIP URIによって識別された新しい参加者に招待を送信する必要があります。
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に示します。このフローは、参照を使用して会議に新しい参加者を追加することを示していますが、メカニズムは一般に、会議にURIによって識別されるリソースを追加できます。アリスはすでに会議の参加者であると想定されています。アリスは会議URIへの紹介を送ります。この焦点は、招待を送ることにより、キャロルを会議に招待します。セッションが確立された後、キャロルは会議URIを購読します。キャロルの購読（F11）とアリスへの通知（F15）に依存していないことに注意することが重要です - それらは非同期的かつ独立して発生します。
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 | |
|------------------->| |
Figure 5. Participant Requests That the Focus Add a Participant to the Conference.
図5.参加者は、焦点が参加者を会議に追加することを要求します。
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
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に招待を送るように要求します。これは、非SIP手段（電子メール、IM、またはWebページでConference URIの合格または公開など）を使用して実行できます。非SIP平均が使用される場合、フローと要件はセクション5.1と同一です。
The SIP mechanism to do this utilizes the REFER method.
これを行うためのSIPメカニズムは、参照方法を使用します。
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.
新しい参加者を追加したいUAは、Conference 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のダイヤルインケースと同じです。魅力的な参加者は、会議パッケージを通じて受け取った通知に加えて、新しい参加者が追加されたという紹介アクションを通じて通知を受け取ることができます。
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に示します。このコールフローでは、アリスはすでに会議の参加者であると想定されています。アリスはボブに「バンドから外れた」紹介、つまり、確立されたダイアログの外側の紹介を送信します。ボブが紹介を拒否した場合、アリスは最初にセッションを確立するためにボブに招待状を送信してから、ダイアログ内で紹介を送信し、ボブを会議に効果的に転送しようとするかもしれません[17]。
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 | |
| |<-------------------| |
Figure 6. Adding a Participant to an Existing Conference.
図6.既存の会議に参加者を追加します。
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.
参加者は、紹介方法を送信して、参加者を会議に紹介することを要求することができます。参照ヘッダーフィールドには、参照する方法が設定されており、会議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.
以下のメッセージF1では、参照ヘッダーフィールドは2行にわたって継続するものとして表示されていることに注意してください。これは実際のメッセージではそうではありません。URIは、このドキュメントのフォーマット制限を超えて継続していたでしょう。
This scenario is shown in Figure 7.
このシナリオを図7に示します。
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 | |
| |<-------------------| |
Figure 7. Requesting That the Focus Refer a Participant to a Conference.
図7.焦点が参加者を会議に紹介するように要求する。
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
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
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: ...
(SDP not shown)
（SDPが表示されていません）
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は、会議の片足（別の参加者とフォーカスの間のダイアログ）のダイアログIDを含む結合[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が参加ヘッダーを使用できる他のシナリオがあります。さらなる例と詳細については、[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として略され、BOBによって知られています。ボブは、ダイアログ識別子a-fを含む結合ヘッダーを含む招待メッセージF1をフォーカスに送信することにより、会議に追加されることを要求します。ボブは焦点によって会議に追加されます。
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 | |
| |<-------------------| |
Figure 8. Adding a Participant to an Existing Conference using Join.
図8.参加者を既存の会議に追加して、参加者を追加します。
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: ...
(SDP not shown)
（SDPが表示されていません）
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.
会議の参加者は、会議に参加するユーザーエージェント（つまり、エンドポイントまたはデバイス）を変更したい場合があります。これは、1つのユーザーエージェントからByeを送信して会議を去るだけで、他のユーザーエージェントから招待を再生することを行うことができます。ただし、SIPの交換[6] Primitiveは、この操作に完全に適しています。
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に切り替え、ダイアログ識別子A-Fを含む交換ヘッダーを含む焦点に招待メッセージF1を送信します。このダイアログ識別子は、いくつかの非SIPメカニズムを介して、またはsubscribe/Notifyおよびダイアログイベントパッケージ[18]を使用して学習できることに注意してください。Aliceのユーザーエージェント＃2は、Focusによって会議に追加されます。フォーカスは、ユーザーエージェント＃1にさようならを送信します。ユーザーエージェント＃1は、サブスクリプションを送信するサブスクライブを送信することにより、サブスクリプションを自動的に終了します。アリスのユーザーエージェント（つまりエンドポイント）に関する詳細情報が会議状態通知に含まれていない限り、参加者リスト（名簿）は必ずしも変更されていないことに注意してください。会議パッケージ通知の完全な議論については、[9]を参照してください。
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 | |
| |<-------------------| |
Figure 9. Switching a User Agent within a Conference.
図9.会議内でユーザーエージェントの切り替え。
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 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.
アリスとボブは、ダイアログ識別子A-Bで確立されたセッションを持っています。アリスは、会議URIに招待を送ることで、焦点を絞って会議に参加します。その後、アリスはフォーカスに紹介リクエストを送信して、他の参加者に招待リクエストを送信します。アリスには、紹介ヘッダーフィールドに含まれるURIのエスケープ交換ヘッダーフィールドが含まれています。ボブはフォーカスから招待状を受け取り、交換ヘッダーフィールドのダイアログとアリスとのダイアログと一致します。その結果、ボブは招待を受け入れ、会議に参加し、アリスにさようならを送り、ポイントツーポイントのダイアログを取り壊します。
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 | |
| |<==================>| |
| 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 | |
| |<-------------------| |
| | | |
Figure 10. Transitioning a Point to Point Session into a Conference.
図10.ポイントツーポイントセッションを会議に移行する。
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（通常、会議の所有者）は、参加者のURIを含む紹介と、さようならに設定されたメソッドを含む会議URIを紹介することができます。。要求者は、フォーカスと削除される参加者との間のダイアログに関するダイアログ情報を知る必要はありません。フォーカスはこの情報を知っており、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に示します。アリスとキャロルはすでに会議の参加者であり、アリスは会議からメンバーを削除することを許可されていると想定されています。アリスは、sip：carol@chicago.example.com; method = byeのフォームのURIを含む紹介ヘッダーを含む会議URIへの紹介を送信します。
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 | |
|------------------->| |
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
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
The default conference policy for conferences created using the Conference Factory URI is that the conference is deleted when the creator departs.
会議工場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は、クリエイターのアリスが出発して会議を削除するこのコールフローを示しています。さようならと最終通知を送信する順序は重要ではないことに注意してください。
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 |
| |<----------------------------------------|
Figure 12. Deleting a Conference.
図12.会議の削除。
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は、不透明なURIが会議URIであるかどうかを発見するためのオプションリクエストを送信する場合があります（フォーカスに解決します）。さらに、オプションリクエストへの返信は、このドキュメントで使用されているさまざまな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.
通常のダイアログ確立プロセスの一部として、許可、受け入れ、イベント、およびサポートされているヘッダーフィールドは、フォーカスまたはフォーカスから招待への招待状に存在する必要があることに注意してください。
An example is shown in Figure 13 where Alice sends an OPTIONS to a URI that resolves to a focus.
例を図13に示します。ここでは、アリスは焦点を解決するURIにオプションを送信します。
Alice Focus Bob Carol
| | | |
| OPTIONS sip:Conf-ID F1 | |
|------------------->| | |
| 200 OK Contact: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: ...
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
Useful information from each of these headers is detailed in the next sections.
これらのヘッダーのそれぞれからの有用な情報については、次のセクションで詳しく説明しています。
Allow. The support of methods such as REFER, SUBSCRIBE, and NOTIFY indicates that the user agent supports call control and SIP events.
許可する。参照、購読、通知などのメソッドのサポートは、ユーザーエージェントがコールコントロールと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].
Allow-Ievents。参照[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.
コンタクト。コンタクトヘッダーに「isFocus」機能パラメーターが存在することは、URIがConference URIであり、UAが焦点であることを示しています。
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の間の相互作用を定義します。その結果、RFC 3261 [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]で説明したように、会議には多くの場合、会議リソースに関連するポリシーがあります。焦点は、参加者を会議に参加させ、会議リソースの利用を可能にする前に、参加者を認証する必要があります。認証の結果に基づいて、異なる参加者に焦点を当てることにより、さまざまなポリシーを適用できます。
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 IDメカニズムを使用したSIPダイジェストなど、参加者とフォーカス認証に適しています。さらに、焦点は安全なSIP接続をサポートし、TLSが提供するホップバイホップの相互認証と機密性を達成できるようにする必要があります。
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ダイアログでは、フォーカスが「ISFOCUS」機能タグを利用して、UAがフォーカスとして機能していることを示します。そのため、接触などのSIPヘッダーフィールドには、エンドツーエンドの完全性が必要です。参加者とフォーカスは、S/MIMEなどのエンドツーエンドの完全性メカニズムをサポートする必要があります。
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コールコントロール操作（参照など）を実装するか、フォーカスの会議パッケージのサブスクリプションを試みることができます。RFC 3515 [4]に記載されているセキュリティ上の考慮事項は、紹介コールコントロール操作に適用されます。フォーカスと参加者は、ポリシーを適用して、どのコールコントロール操作が許可されているかを判断します。
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.
会議パッケージへのサブスクリプションを受け入れる焦点は、RFC 4575 [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.
焦点は、会議ポリシーを通じて、または信号を通じて表明されたように、参加者のプライバシーの要求をサポートする必要があります。たとえば、会議に参加してプライバシーヘッダーフィールド[10]を含む参加者は、フォーカスによって他の参加者にID情報を明らかにしてはなりません。他のシグナル伝達プロトコルを使用する場合、それらを介して信号を送信されたプライバシーも尊重する必要があります。
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 Mahy、Jonathan Rosenberg、Roni Even、Petri Koskelainen、Brian Rosen、Paul Kyzivat、Eric Burgerなどに感謝します。
Thanks to Miguel Garcia for his detailed last-call review and suggestions.
彼の詳細な最後のレビューと提案をしてくれたミゲル・ガルシアに感謝します。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、 "SIP：SESSION INTIATION Protocol"、RFC 3261、2002年6月。
[3] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[3] Roach、A。、「セッション開始プロトコル（SIP）特異的イベント通知」、RFC 3265、2002年6月。
[4] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[4] Sparks、R。、「セッション開始プロトコル（SIP）参照メソッド」、RFC 3515、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] Rosenberg、J.、Schulzrinne、H。、およびP. Kyzivat、「セッション開始プロトコル（SIP）のユーザーエージェント機能を示す」、RFC 3840、2004年8月。
[6] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation Protocol (SIP) "Replaces" Header", RFC 3891, September 2004.
[6] Mahy、R.、Biggs、B。、およびR. Dean、「セッション開始プロトコル（SIP）」「ヘッダー」、RFC 3891、2004年9月に置き換えられます。
[7] Mahy, R. and D. Petrie, "The Session Initiation Protocol (SIP) "Join" Header", RFC 3911, October 2004.
[7] Mahy、R。およびD. Petrie、「セッション開始プロトコル（SIP）」「Header」に参加、RFC 3911、2004年10月。
[8] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol (SIP)", RFC 4353, February 2006.
[8] Rosenberg、J。、「セッション開始プロトコル（SIP）との会議のフレームワーク」、RFC 4353、2006年2月。
[9] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session Initiation Protocol (SIP) Event Package for Conference State", RFC 4575, August 2006.
[9] Rosenberg、J.、Schulzrinne、H。、およびO. Levin、「会議州のセッション開始プロトコル（SIP）イベントパッケージ」、RFC 4575、2006年8月。
[10] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002.
[10] ピーターソン、J。、「セッション開始プロトコル（SIP）のプライバシーメカニズム」、RFC 3323、2002年11月。
[11] Campbell, B. and R. Sparks, "Control of Service Context using SIP Request-URI", RFC 3087, April 2001.
[11] Campbell、B。およびR. Sparks、「SIP Request-URIを使用したサービスコンテキストの制御」、RFC 3087、2001年4月。
[12] Sparks, R., "Internet Media Type message/sipfrag", RFC 3420, November 2002.
[12] Sparks、R。、「インターネットメディアタイプメッセージ/Sipfrag」、RFC 3420、2002年11月。
[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] Johnston、A.、Donovan、S.、Sparks、R.、Cunningham、C。、およびK. Summers、「セッション開始プロトコル（SIP）基本的なコールフローの例」、BCP 75、RFC 3665、2003年12月。
[14] Levin, O. and R. Even, "High Level Requirements for Tightly Coupled SIP Conferencing", RFC 4245, November 2005.
[14] レビン、O。、およびR.
[15] Mahy, R., "A Call Control and Multi-party usage framework for the Session Initiation Protocol (SIP)", Work in Progress, February 2005.
[15] Mahy、R。、「セッション開始プロトコル（SIP）のコールコントロールとマルチパーティの使用フレームワーク」、2005年2月の作業。
[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] Rosenberg、J。、「セッション開始プロトコル（SIP）でグローバルにルーティング可能なユーザーエージェント（UA）URIS（GRUU）を取得および使用している」、2005年2月、Work in Progress。
[17] Sparks, R., Johnston, A., and D. Petrie, "Session Initiation Protocol Call Control - Transfer", Work in Progress, April 2005.
[17] Sparks、R.、Johnston、A。、およびD. Petrie、「セッション開始プロトコルコールコントロール - 転送」、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] Rosenberg、J.、Schulzrinne、H。、およびR. Mahy、「セッション開始プロトコル（SIP）の招待状のダイアログイベントパッケージ」、RFC 4235、2005年11月。
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を操作する人間のユーザーが、参加者を会議に作成して追加できる方法について説明します。この方法は、推奨されていないため、付録として説明されています。このシナリオでは、アドホックまたはマニュアル手段を使用した会議の作成を含むシナリオが推奨されます。ただし、このシナリオは完全性のために含まれています。
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.
ユーザー（Human）は、システムルールに従ってConference URIを選択し、招待状のリクエスト-uriに挿入します。この同じURIは、焦点によってコンタクトヘッダーの特定のアドレス指定条約（以下で説明）を順守するフォーカスによって反映されています。追加の参加者は、非SIP手段（Webページ、電子メール、IMなどを使用して、選択した会議URIの公開）によって追加される可能性があります。あるいは、会議とアウェアのUAは、SIPコールコントロールを使用してセッションを確立することで他の参加者を会議に追加し、[17]を会議URIに転送することができます。このシナリオでは、ユーザー（Human）のみが会議アプリケーションを認識しており、会議に出場しないUAはサポートRFC 3261 [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は、フォーカスに解決します。焦点は、conf.example.comドメインの未知のユーザー部分を、会議URIがリクエスト-URIとして作成するための会議のリクエストとして解釈するように構成できます。たとえば、sip：k32934208ds72@conf.example.comのリクエスト-uriで送信された招待状は、会議を作成するフォーカスにルーティングできます。この会議URIは、新しく作成されたフォーカスによって登録され、conf.example.comドメイン内の会議URIとしてルーティング可能になる必要があります。返された連絡先は次のように見えます。
Contact: <sip:k32934208ds72@conf.example.com>;isfocus
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に招待を送信します。焦点は会議を作成し、招待に対する200 OKの回答で同じ会議URIを返します（これはカンファレンスとアウェアのUAによって無視されます）。
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 | | |
|<==================>| | |
Figure 14. Not Recommended: Conferencing Unaware Participant Creates a Conference
図14.推奨されていません：知らない参加者の会議が会議を作成する
Authors' Addresses
著者のアドレス
Alan Johnston Avaya St. Louis, MO 63102
アラン・ジョンストン・アヴァヤ・セントルイス、ミズーリ州63102
EMail: alan@sipstation.com
Orit Levin Microsoft Corporation One Microsoft Way Redmond, WA 98052
Orit Levin Microsoft Corporation One Microsoft Way Redmond、WA 98052
EMail: oritl@microsoft.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。