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
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).
著作権（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.
この仕様は、セッション開始プロトコル（SIP）のための会議通話制御機能を定義します。この文書では、密結合SIP会議がどのように機能するかを定義するために会議の要件と枠組み文書に基づいています。 、会議非対応会議対応、とUASを集中：アプローチは、異なるユーザエージェント（UA）タイプの観点から探求されています。会議でのURI（Uniform Resource Identifier）の使用、能力発見のためのオプション、およびREFER使用してコントロールを呼び出すには例のコール・フロー図で詳細に覆われています。 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ダイアログを確立します。焦点は、制御、認証、および承認の中心点です。この仕様は、焦点と参加者のUAの動作を定義します。唯一のシグナリング（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).
1つの会議は、潜在的に異なる手段（すなわち、ダイヤルイン、ダイヤルアウト、スケジュールされた、またはアドホック）で会議に参加しているさまざまな機能とを持っている参加者をブリッジできることに注意してください。
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.
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].
この文書では、キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "NOT SHALL"、 "推奨"、 "すべきではない" "べきである" "ないものと"、 "MAY"、および "オプション" 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]、そのパッケージの通知として動作し、要求と応答で許可・イベントヘッダフィールドにそのサポートを示します。焦点は、セッション記述プロトコル（SDP）、URIをセッション情報を取り込むことにより、通常の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つのエンドポイント間で確立されたセッションは、集中型会議に移行することができる高度な機能をサポートするために、焦点は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.
その主なタスクを同時に任意のタイプおよびサイズの会議をホストする専用の会議サーバは、アドホック会議（及び続いてその焦点の任意の数を作成するための会議ファクトリー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.
フレームワークによると、会議を作成することができる多くの方法があります。会議サーバの実装は、SIP、または任意の会議制御プロトコル（たとえば、対話型音声応答（IVR）システムのような）非自動化手段を含むこれらの方法から自由に選択することができます。
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]。彼らはSIPコールフロードキュメントのものと同一であるとして会議を意識しないUAのは、この文書で一般的に示されていないため、コールは[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.
それは、標準SIP行動ごとに、未知のヘッダパラメータとして扱われ、無視されますので、Contactヘッダーフィールドに「isfocus」フィーチャータグの存在が焦点と会議を意識しない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.
カンファレンスを意識するユーザエージェントは、[2] RFC 3261のサポートに加えて、会議参加者として、この文書で定義された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] REFERサポートしなければならない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.
「isfocus」パラメータはダイアログのリモートターゲットURIであり、会議パッケージを許可 - イベントに焦点によってリストされている場合は、フィールドをヘッダー場合カンファレンスを意識するUAは、会議パッケージに加入すべきです。会議パッケージに加入するには、任意のINVITE-開始ダイアログ外で送ってください。 BYEとINVITEダイアログの終了は、必ずしもSUBSCRIBEダイアログを終了しません。
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の拡張機能や会議のための規則の開発のための主要な設計ガイドラインは、拡張の最小数を定義するには、会議を意識しない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.
撮影したアプローチは、SIPダイアログが会議に属していることを表現する特徴パラメータ「isfocus」を使用することです。 UAの特性および機能を説明するためのContactヘッダーフィールドにおける特徴パラメータの使用は、「isfocus」特徴パラメータの定義を含むユーザエージェント機能文書[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.
焦点は、それが焦点であるという事実を隠すことを希望しない限り、セッション確立では、フォーカスは、Contactヘッダーフィールドに「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.
その性質上、この仕様でサポートされている会議は、集中しています。そのため、一般的に会議システムは、このURIにSIPリクエストがフォークされず、専用の会議フォーカスにルーティングされるようにSIPカンファレンスURIを割り当てる必要があります。例えば、グローバルにアクセス可能なSIP会議はよくあるため、非フォークとグローバルルータビリティ要件をサポートする能力、（[16]で定義される）グローバルにルーティング可能なユーザエージェントURI（GRUU）を使用して会議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が与えられると、可能です。この発見機能は、OPTIONS要求を使用して、SIPに実装することができ、アクティブなダイアログの内部またはダイアログ外のいずれかで行うことができます。焦点は、それが焦点であるという事実を隠すことを希望しない限り、焦点はOPTIONSに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.
会議要求[14]及び枠組み[8]の文書に記載されているように、このセクションで説明SIP会議呼制御フローは、種々の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は、ダイヤルインする会議の最初の参加者である場合、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は、会議URIへのRequest-URIを設定してINVITEを送信します。焦点はINVITEに対する200 OK応答のContactヘッダーフィールドに「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: ...
F1は、SIP INVITE：3402934234@conf.example.comをSIP / 2.0経由：SIP / 2.0 / UDP client.chicago.example.com;ブランチ= z9hG4bKhjhs8ass83マックス・フォワード：70：<SIP：3402934234@conf.example.com> From：キャロル<SIP：carol@chicago.example.com>;タグ= 32331コールID：d432fa84b4c76e66710ののCSeq：45連絡先をINVITE：<SIP：carol@client.chicago.example.com>許可：INVITE、ACKは、CANCEL、 OPTIONSは、BYE、SUBSCRIBE、REFER、許可 - イベントをNOTIFY：ダイアログが受け入れ：アプリケーション/ SDP、メッセージ/ sipfragがサポートされている：アプリケーション/ SDPのContent-Length：Content-Typeのを置き換え...
(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: ...
F3 SIP / 2.0 200 OK経由：SIP / 2.0 / UDP client.chicago.example.com;ブランチ= z9hG4bKhjhs8ass83は、受信= 192.0.2.4へ：<SIP：3402934234@conf.example.com>;からタグ= 733413：キャロル<一口：carol@chicago.example.com>;タグ= 32331コールID：d432fa84b4c76e66710ののCSeq：45問い合わせINVITE：<SIP：3402934234@conf.example.com>を、isfocus許可：BYE、INVITE、ACK、CANCEL、OPTIONS 、SUBSCRIBE、REFER許可 - イベントNOTIFY：ダイアログ、会議受け入れ：アプリケーション/ SDP、アプリケーション/会議-情報+ xmlの、サポートされているメッセージ/ sipfrag：、参加置き換え、GRUUのContent-Type：アプリケーション/ SDPコンテンツの長さを.. 。
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
F5は、SIP SUBSCRIBE：3402934234@conf.example.comをSIP / 2.0経由：SIP / 2.0 / UDP client.chicago.example.com;ブランチ= z9hG4bKdf334マックス・フォワード：70：<SIP：3402934234@conf.example.com>キャロル<SIP：carol@chicago.example.com>から、タグが= 43524545コールID：k3l43id034kserereeのCSeq：22連絡先をSUBSCRIBE：<SIP：carol@client.chicago.example.com>許可：、、INVITE ACK、CANCEL OPTIONS、BYE、イベントをNOTIFY、SUBSCRIBE、REFER：会議は受け入れ：アプリケーション/会議-情報+ XMLがサポートされている：コンテンツ長を置き換え：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
F7は、SIP NOTIFY：carol@chicago.example.comをSIP / 2.0経由：SIP / 2.0 / UDP ms5.conf.example.com;ブランチ= z9hG4bK3343d1マックス・フォワード：70：キャロル<SIP：carol@chicago.example.com >;タグ= 43524545から：<SIP：3402934234@conf.example.com>;タグ= a3343df32のCall-ID：k3l43id034kserereeのCSeq：<一口：34321連絡先NOTIFY 3402934234@conf.example.com>を、isfocus許可：INVITE、 ACK、イベントをNOTIFY、SUBSCRIBE、BYE、REFER、OPTIONSをCANCEL：会議は受け入れ：アプリケーション/ SDP、メッセージ/ sipfragサブスクリプション・状態：アクティブ; 3600がサポートされている=有効期限が切れる：参加、置き換え、GRUUのContent-Type：アプリケーション/会議-情報+ 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"> <会議-記述> <CONF-のURI> <エントリー> <URI> TEL：18882934234 </ URI> </ entry>の</ confに-のURI> </会議-記述> <ユーザー> <ユーザエンティティ= "一口：carol@chicago.example.com" 状態= "フル"> <表示テキスト>キャロル</表示テキスト> <エンドポイントエンティティ= "SIP：carol@client.chicago.example.com"> <状態>接続</ステータス> <接合法>ダイヤルイン</接合法> <メディアID = "1 「> <表示テキスト>メインオーディオ<> <タイプ>オーディオ</タイプ> <SRC-ID> 583398 </ SRC-ID> <状態> SENDRECV </状態> </メディア> <メディアID /表示テキスト= "2"> <タイプ>ビデオ</タイプ> <SRC-ID> 345212 </ SRC-ID> <状態>のsendrecv </ステータス> </メディア> </エンドポイント> </ユーザー> </ユーザー> < /会議-インフォメーション>
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」機能のパラメータを持つContactヘッダーフィールドを含む参加者に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の観点から）セッションを扱うことに注意してください。標準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に示されています。焦点はINVITEを送信することにより、会議にキャロルを誘います。セッションが確立された後、キャロルは、会議URIにサブスクライブします。キャロルのSUBSCRIBE（F5）とアリス（F9）にNOTIFYには依存関係がないことに注意することが重要である - 彼らは非同期に独立して起こります。
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. Aフォーカスが会議に参加者を追加する「ダイヤルアウト」。
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は、SIP NOTIFY：carol@chicago.example.comをSIP / 2.0経由：SIP / 2.0 / UDP ms5.conf.example.com;ブランチ= z9hG4bK3343d1マックス・フォワード：70：キャロル<SIP：carol@chicago.example.com >;タグ= 43524545から：<SIP：3402934234@conf.example.com>;タグ= a3343df32のCall-ID：k3l43id034kserereeのCSeq：<一口：34321連絡先NOTIFY 3402934234@conf.example.com>を、isfocus許可：INVITE、 ACKは、CANCEL、OPTIONSは、BYE、REFER、SUBSCRIBEイベントをNOTIFY：会議は受け入れ：アプリケーション/ SDP、メッセージ/ sipfrag購読-状態：アクティブ; = 3600サポート期限が切れる：置き換え、GRUUのContent-Type：アプリケーション/会議-情報+ XMLをコンテンツの長さ：...
<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: ...
F9は、SIP NOTIFY：alice@atlanta.example.comをSIP / 2.0経由：SIP / 2.0 / UDP ms5.conf.example.com;ブランチ= z9hG4bK3432マックス・フォワード：70：アリス<SIP：alice@atlanta.example.com >;タグから= 43524545：<SIP：3402934234@conf.example.com>;タグ= a3343df32のCall-ID：8820450524545のCSeq：998は、連絡先をNOTIFY：<SIP：3402934234@conf.example.com>; isfocus許可：INVITE、 ACKは、CANCEL、OPTIONSは、BYE、REFER、SUBSCRIBEイベントをNOTIFY：会議は受け入れ：アプリケーション/ SDP、メッセージ/ sipfrag購読-状態：アクティブ; = 2450サポート期限が切れる：置き換え、GRUUのContent-Type：アプリケーション/会議-情報+ XMLをコンテンツの長さ：...
<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>
5.3. INVITE: Manually Creating a Conference by Dialing in to a Conferencing Application
5.3. INVITE：手動で会議アプリケーションにダイヤルすることで会議を作成します
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システムまたはウェブページなどの）アプリケーションが実装されます。通常のダイアログが確立された後、追加の情報が受信され、その焦点と一緒に会議が作成されます。 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の初期ダイアログの議論については[2] RFC 3261を参照）初期対話中にユーザによって提供され得ます。これは、会議アプリケーションによって送信された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に示され、アリスは、アリスは、会議アプリケーションにINVITEを送信するときにトリガーされる会議のアプリケーションを使用します。この例では、コンファレンスアプリは、会議アプリケーションURIを表すために使用されます。アリスのカンファレンスを意識する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がユーザーに知られていない必要があるということです。代わりに、それはフォーカスによって作成され、参加者のUAによって使用されます。このシナリオとセクション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は、（SIP電話機のボタン「新しい会議を作成する」のように）UAにプロビジョニングすることができ、または他の手段を用いて発見することができます。
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によって、既存の会議に参加するための要求から新しいアドホック会議を作成するための要求として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を使用して作成されますが会議URIであるOK 200に戻りました。 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.
例えば、コールフローは、コンファレンス・ファクトリーは、会議工場のURIの省略形で、コンファレンス-IDが会議URIのために短いことが、図4に示す注意されます。この流れでは、Aliceはカンファレンスを意識するUAがあり、会議工場のURIにINVITEを送信することで、会議を作成します。会議工場アプリケーションは、会議を作成し、302一時的に移動応答を使用して焦点にアリスをリダイレクトします。プロキシ再帰と正常RFC 3261 [2]動作の一部として、アリスはリダイレクトを見ることはないかもしれないが、単にメッセージF5始まる焦点からの応答を受信してもよいことに留意されたいです。メディアセッションが確立されると、アリスはURIが焦点から200 OK応答で連絡先を経て得られた会議に加入します。
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.
SIPアドホックメソッドを使用して会議の図4.作成。
5.5. REFER: Requesting a Focus to Add a New Resource to a Conference (Dial Out to a New Participant)
5.5. REFER：会議に新しいリソースを追加するためにフォーカスを要求する（新しい参加者にダイヤルアウト）
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は、会議への情報の種類を注入するために使用することができます。例としては、（HTTPのURIなど）の受動的な情報の参照に新しい参加、新しいリアルタイムメディアソース、新しいIMメッセージ、およびポインタを含みます。
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にREFERを送信することができます。このREFERは会議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.
唯一の要求参加者とフォーカスは、REFERと転送呼制御をサポートする必要がある - それは、新たな参加者がREFERと転送呼制御をサポートしていない場合でも動作するため、新しい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をSIPカンファレンスURIと「isfocus」機能パラメータでContactヘッダーフィールドを含むことで識別される新しい参加者にINVITEを送信すべきである（SHOULD）含むREFERを受信すると、 。
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.
このフローは、会議に新しい参加者を追加するために、REFERの使用を示しているが、例えばコールフローは、図5に示され、機構は、一般的に会議にURIによって識別されるリソースを追加することができます。アリスが会議の参加者がすでにあると仮定されます。アリスは、会議URIにREFERを送信します。焦点はINVITEを送信することにより、会議にキャロルを誘います。セッションが確立された後、キャロルは、会議URIにサブスクライブします。キャロルのSUBSCRIBE（F11）とアリス（F15）にNOTIFYには依存関係がないことに注意することが重要である - 彼らは非同期に独立して起こります。
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
F1は、SIP REFER：3402934234@conf.example.comをSIP / 2.0経由：SIP / 2.0 / UDP client.atlanta.example.com;ブランチ= z9hG4bKg4534マックス・フォワード：70：<SIP：3402934234@conf.example.com>アリス<SIP：alice@atlanta.example.com>から、タグが= 5534562コールID：849392fklgl43のCSeq：476の連絡先を参照してください。<SIP：alice@alice.example.com>許可：、INVITE ACK、CANCEL、OPTIONS、アプリケーション/ SDPを、メッセージを/ sipfrag参照してください-TO：<SIP：carol@chicago.example.com>サポート：BYE、受け入れREFER、SUBSCRIBE、NOTIFYのContent-Lengthを置き換え：0
5.6. REFER: Requesting a User to Dial in to a Conference Using a Conference URI
5.6. REFER：会議の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を送信するには、この参加者を要求します。これは、（例えば、電子メール、IM、またはWebページで会議URIを渡すか、出版など）非SIP手段を用いて行うことができます。非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.
新しい参加者を追加したいUAは、参照してください-するには会議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を拒否すべきである、アリスは、[17]そして効果的に会議にボブを転送し、ダイアログ内REFERを送り、最初のセッションを確立するために、ボブにINVITEを送信してみてください。
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。
5.7. REFER with REFER: Requesting a Focus to Refer a Participant to Dial in to the Conference
5.7. REFERを参照してください。会議にダイヤルインする参加者を参照してくださいにフォーカスを要求
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メソッドを送信することにより、会議に参加者を指すことを要求することができます。参照のために、ヘッダフィールドが参照するように設定方法を有し、参照のために、会議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
F1は、SIP REFER：3402934234@conf.example.comをSIP / 2.0経由：SIP / 2.0 / UDP client.atlanta.example.com;ブランチ= z9hG4bKg4534マックス・フォワード：70：<SIP：3402934234@conf.example.com>アリス<SIP：alice@atlanta.example.com>から、タグが= 5534562コールID：849392fklgl43のCSeq：476の連絡先を参照してください。<SIP：alice@alice.example.com>許可：、INVITE ACK、CANCEL、OPTIONS、アプリケーション/ SDPを、メッセージ/ sipfrag参照してください-TO：BYE、受け入れREFER、SUBSCRIBE、NOTIFY <SIP：bob@biloxi.example.com;方法= REFER参照してください-TO =一口：？3402934234% 40example.com>サポート：置き換えコンテンツの長さ：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は、SIP REFER：3402934234@conf.example.comをSIP / 2.0経由：SIP / 2.0 / UDP ms5.conf.example.com;ブランチ= z9hG4bK33445243マックス・フォワード：70：<SIP：bob@biloxi.example.com> From：<SIP：3402934234@conf.example.com>;タグ= 345621412コール-ID：5494204のCSeq：4524323連絡先を参照してください。<SIP：3402934234@conf.example.com>;許可isfocus：INVITE、ACK、CANCEL、OPTIONSアプリケーション/ SDP、メッセージ/ sipfrag参照してください-TO：<SIP：3402934234@conf.example.com>サポート：、BYE、SUBSCRIBE、REFER、受け入れNOTIFY参加し、GRUUは、コンテンツの長さを置き換える：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、SIP INVITE：3402934234@conf.example.com SIP / 2.0経由：SIP / 2.0 / UDP client.biloxi.com;ブランチ= z9hG4bKh3887マックス・フォワード：70：<SIP：3402934234@conf.example.com>から：ボブ<SIP：bob@biloxi.example.com>;タグは= 32411コールID：5d4324fa84b4c76e66710のCSeq：764の連絡先をINVITE：<SIP：bob@client.biloxi.example.com>許可：、INVITE ACK、CANCEL、OPTIONS、 BYE、REFER、SUBSCRIBE、許可 - イベントをNOTIFY：ダイアログが受け入れ：アプリケーション/ SDP、メッセージ/ sipfragがサポートされている：アプリケーション/ SDPコンテンツの長さ：：、コンテンツタイプに参加置き換え...
(SDP not shown)
（SDP図示せず）
5.8. Join Header Field: Dialing in to a Conference Using a (3rd Party) Dialog Identifier
5.8. 参加ヘッダーフィールド：（サード・パーティ）を使用して会議にダイヤルインするダイアログ識別子
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.
いくつかの状況下では、会議に参加したい参加者は会議の足の一つのダイアログ識別子を知っているかもしれません。情報は、[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と略記され、ボブに知られています。ボブは、ダイアログ識別子A-Fを含有する参加ヘッダを含む焦点にINVITEメッセージ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: ...
ブランチ= z9hG4bKh3832マックス・転送し、SIP / 2.0 / UDP client.biloxi.com：70：<SIP：3402934234@conf.example.com>から：3402934234@conf.example.com SIP / 2.0経由：F1は、SIPのINVITEボブ<SIP：bob@biloxi.example.com>;タグ= 32411コールID：d432fa84b4c76e66710ののCSeq：8連絡先をINVITE：<SIP：bob@client.biloxi.example.com>は参加：3434034から293553453を;にタグ= fdj3l34;からタグ= 12f331は許可：、INVITE ACK、CANCEL、OPTIONS、BYE、REFER、SUBSCRIBE、許可 - イベントをNOTIFY：ダイアログが受け入れ：アプリケーション/ SDP、メッセージ/ sipfragがサポートされている：置き換え、Content-Typeの参加：アプリケーション/ SDPをコンテンツの長さ：...
(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.
会議の参加者は、彼らが会議に参加すると、ユーザエージェント（すなわち、エンドポイントまたはデバイス）を変更することもできます。これは単に会議を離れ、再度参加する他のユーザエージェントからINVITEを1つのユーザーエージェントからBYEを送信することにより行うことができます。しかしながら、SIPは、[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].
例では、アリスがユーザエージェント＃1を使用して、会議の参加者であると仮定される図9に示されています。 Aliceのユーザーエージェント＃1と焦点との間のダイアログ識別子は-Fと略記します。アリスは、ユーザエージェント＃2に切り替わり、ダイアログ識別子A-Fを含有するReplacesヘッダーを含む焦点にINVITEメッセージF1を送信します。このダイアログ識別子は、いくつかの非SIP機構を介して、またはSUBSCRIBE / NOTIFYを使用すると、ダイアログイベントパッケージによって学習することができることに留意されたい[18]。 Aliceのユーザーエージェント＃2は、フォーカスによってカンファレンスに追加されます。焦点は、ユーザエージェント＃1にBYEを送信します。 0サブスクリプションを終了するには：ユーザーエージェント＃1は、自動的に期限切れにSUBSCRIBE送信することによって、サブスクリプションを終了します。アリスのユーザエージェント（すなわち、エンドポイント）についての詳細な情報は、会議状態通知に含まれていない限り参加者リスト（名簿）は、必ずしも、このシナリオの間に変更されていないことに留意されたいです。会議パッケージ通知の完全な議論については、[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は、会議中にユーザーエージェントを切り替えます。
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 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にINVITEを送信することによって、焦点と会議に参加します。アリスは、他の参加者にINVITEリクエストを送信するために焦点にREFERリクエストを送信します。アリスは、参照のために、ヘッダフィールドに含まエスケープURIヘッダフィールドを置き換え含みます。ボブは、焦点からINVITEを受信し、アリスとの対話に置換ヘッダフィールドのダイアログと一致します。その結果、ボブは、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 | |
| |<==================>| |
| 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は、会議へのセッションをポイントツーポイントに移行。
5.11. REFER with BYE: Requesting That the Focus Remove a Participant from a Conference
5.11. BYEを参照してください。フォーカスは、会議から参加者を削除するよう要求します
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を含み、BYEに設定方法との会議URIにREFERを送信することができ。リクエスタは削除されます焦点と参加者間の対話に関する対話情報を知る必要はありません - 焦点は、この情報を知っていて、それが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に示されています。 BYE =法; carol@chicago.example.com：アリスは、参照のために、フォームのSIP 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
F1は、SIP REFER：3402934234@conf.example.comをSIP / 2.0経由：SIP / 2.0 / UDP client.atlanta.example.com;ブランチ= z9hG4bKg4534マックス・フォワード：70：<SIP：3402934234@conf.example.com>アリス<SIP：alice@atlanta.example.com>から、タグが= 5534562コールID：849392fklgl43のCSeq：476の連絡先を参照してください。<SIP：alice@alice.example.com>許可：、INVITE ACK、CANCEL、OPTIONS、 BYE、REFER、SUBSCRIBE、受け入れNOTIFY：アプリケーション/ SDP、メッセージ/ご参照ください-へのsipfrag：<SIP：carol@chicago.example.com;メソッドは= BYE>サポート：コンテンツ長を置き換え：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
F5 BYEのSIP：carol@client.chicago.example.com SIP / 2.0経由：SIP / 2.0 / UDP ms5.conf.example.com;ブランチ= z9hG4bK343gf4マックス・フォワード：70から：<SIP：3402934234@conf.example。コム>;タグ= 5393k2312へ：キャロル<SIP：carol@chicago.example.com>;タグ= 32331コール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は、作成者アリスは、会議が削除させる逸脱するこのコールフローを示します。送信不戦勝と最終のNOTIFYの順序は重要ではないことに注意してください。
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（フォーカスに解決）であれば発見する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.
、許可同意、許可・イベント、およびサポートされているヘッダフィールドがフォーカスまたは通常のダイアログ確立プロセスの一部として、INVITEに焦点から200 OK回答からINVITE中に存在すべきであることに留意されたいです。
An example is shown in Figure 13 where Alice sends an OPTIONS to a URI that resolves to a focus.
例はアリスが焦点に解決URIにOPTIONSを送信し、図13に示されています。
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: ...
F2 SIP / 2.0 200 OK経由：SIP / 2.0 / UDP pc33.atlanta.example.com;分岐= z9hG4bKhjsas87は、受信= 192.0.2.4に<SIP：3402934234@conf.example.com>;からタグ= 93810874：アリス<一口：alice@atlanta.example.com>;タグは= 1928301774コールID：a84b4c76e66710のCSeq：63104 OPTIONS連絡先：<SIP：3402934234@conf.example.com>; isfocus許可：BYE、INVITE、ACK、CANCEL、OPTIONS 、SUBSCRIBE、REFER、許可 - イベントをNOTIFY：参照し、会議は受け入れ：アプリケーション/ SDPを、メッセージ/ sipfrag言語を受け入れ：サポートエン：参加、置き換え、GRUUのContent-Type：アプリケーション/ SDPコンテンツの長さ：...
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.
許可します。こうした、REFER、SUBSCRIBE、および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が焦点であることを示しています。
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ダイジェスト認証など、または証明書、またはセキュアなSIPアイデンティティメカニズムに適しています。 TLSによって提供されるホップバイホップ相互認証及び機密性を達成することができるように加えて、焦点は、セキュア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」フィーチャータグを利用します。このように、このようなコンタクトとして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が焦点であることを知っていたら、（例えばREFERなど）のSIP呼制御操作を実現することができる、またはフォーカスの会議パッケージへのサブスクリプションが試みられている可能性があります。 RFC 3515に記載されているセキュリティの考慮事項[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.
会議パッケージにサブスクリプションを受け入れる焦点は、[9] RFC 4575のセキュリティ上の考慮事項に従わなければなりません。通知は、機密情報を運ぶことができるので、サブスクリプションは、認証されたとの通知は、機密性と完全性保護を提供する必要があります。参加者は、直接他の参加者を認証することができませんので、参加者はこの認証を実行するために、焦点に依存しなければなりません。
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]、フォーカスすることにより、他の参加者に明らかに識別情報を持っていなければなりません。他のシグナリングプロトコルが使用されている場合は、それらを介して合図プライバシーも尊重されなければなりません。
We would like to thank Rohan Mahy, Jonathan Rosenberg, Roni Even, Petri Koskelainen, Brian Rosen, Paul Kyzivat, Eric Burger, and others in list discussions.
私たちは、リストの議論にロハンマーイ、ジョナサン・ローゼンバーグ、ロニでも、ペトリKoskelainen、ブライアン・ローゼン、ポールKyzivat、エリックバーガー、そして他の人に感謝したいと思います。
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]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[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.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[3] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[3]ローチ、A.、 "セッション開始プロトコル（SIP）特異的イベント通知"、RFC 3265、2002年6月。
[4] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[4] 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]ローゼンバーグ、J.、Schulzrinneと、H.、およびP. Kyzivatを、RFC 3840、2004年8月 "セッション開始プロトコル（SIP）におけるユーザエージェントの能力を示します"。
[6] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation Protocol (SIP) "Replaces" Header", RFC 3891, September 2004.
[6]マーイ、R.、ビッグス、B.、およびR.ディーンを、 "セッション開始プロトコル（SIP） "は、" ヘッダ" を置き換えRFC 3891、2004年9月。
[7] Mahy, R. and D. Petrie, "The Session Initiation Protocol (SIP) "Join" Header", RFC 3911, October 2004.
[7]マーイ、R.とD.ペトリー、 "セッション開始プロトコル（SIP）は、 "" ヘッダ"、RFC 3911、2004年10月に参加しましょう。
[8] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol (SIP)", RFC 4353, February 2006.
[8]ローゼンバーグ、J.、RFC 4353、2006年2月 "セッション開始プロトコル（SIP）との会議のためのフレームワーク"。
[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.レヴィン、 "Aセッション開始プロトコル（SIP）の会議の状態のためのイベントパッケージ"、RFC 4575、2006年8月。
[10] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002.
[10]ピーターソン、J.、RFC 3323、2002年11月 "セッション開始プロトコル（SIP）のためのプライバシーメカニズム"。
[11] Campbell, B. and R. Sparks, "Control of Service Context using SIP Request-URI", RFC 3087, April 2001.
[11]キャンベル、B.及びR.スパークス、RFC 3087、2001年4月 "SIP要求URIを使用して、サービス・コンテキストの制御"。
[12] Sparks, R., "Internet Media Type message/sipfrag", RFC 3420, November 2002.
[12]スパークス、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]ジョンストン、A.、ドノバン、S.、スパークス、R.、カニンガム、C.、およびK.サマーズ、 "セッション開始プロトコル（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.、 "密結合SIP会議のための高レベルの要件"、RFC 4245、2005年11月。
[15] Mahy, R., "A Call Control and Multi-party usage framework for the Session Initiation Protocol (SIP)", Work in Progress, February 2005.
[15]マーイ、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]ローゼンバーグ、J.、進歩、2005年2月に仕事 "セッション開始プロトコル（SIP）におけるグローバルにルーティング可能なユーザエージェント（UA）のURI（GRUU）の取得と使用" を参照してください。
[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] RFC 4235 "セッション開始プロトコル（SIP）のためのINVITEが開始ダイアログイベントパッケージ" ローゼンバーグ、J.、Schulzrinneと、H.、およびR.マーイ、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.
ユーザ（人間）は、システム規則に従って会議URIを選択し、INVITEの要求URIに挿入することになります。この同じURIはフォーカスによってContactヘッダ内（以下に説明）特定のアドレッシング規則に付着フォーカスによってエコーされます。追加の参加者は、非SIP手段（Webページ、電子メール、IMなどを使用して、選択された会議URIの公表）によって追加することができます。会議URIに[17]、それらを別の方法として、会議を意識しないUAはその後、彼らとのセッションを確立することにより、SIP呼制御を使用して会議に他の参加者を追加することができ、その後転送します。このシナリオでのみユーザ（人間）が会議アプリケーションを認識していることに注意してください、そして会議を意識しない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が焦点に解決します。焦点は、Request-URIとして会議URIを使用して作成される会議の要求としてconf.example.comドメイン内の未知のユーザ部分を解釈するように構成することができます。その後、会議を作成することになり、焦点にルーティングすることができk32934208ds72@conf.example.com：たとえば、SIPの要求URIに送信されたINVITE。この会議URIはconf.example.comドメイン内の会議URIとしてルーティング可能になるために、新しく作成されたフォーカスによって登録されなければなりません。次のように返された連絡先になります。
Contact: <sip:k32934208ds72@conf.example.com>;isfocus
連絡先：<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).
例コールフローは、参加者アリスが会議URIを作成し、図14に示されている（いくつかの規則を使用してフォーカスドメインと合意）、フォーカスを作成するそのURIにINVITEを送信します。フォーカスは、会議を作成し、（会議を意識しないUAによって無視される）INVITEに対する200 OKの回答で、同じ会議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 | | |
|<==================>| | |
Figure 14. Not Recommended: Conferencing Unaware Participant Creates a Conference
図14は、推奨されない：会議気づいていない参加者は、会議を作成します。
Authors' Addresses
著者のアドレス
Alan Johnston Avaya St. Louis, MO 63102
アラン・ジョンストンアバイアセントルイス、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
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（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.
この文書では、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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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）によって提供されます。