[要約] RFC 4575は、会議の状態を管理するためのSession Initiation Protocol（SIP）イベントパッケージに関する規格です。このRFCの目的は、SIPを使用して会議の状態を追跡し、通信プロトコル間での一貫性を確保することです。
Network Working Group J. Rosenberg
Request for Comments: 4575 Cisco Systems
Category: Standards Track H. Schulzrinne
Columbia University
O. Levin, Ed.
Microsoft Corporation
August 2006
A Session Initiation Protocol (SIP) Event Package for Conference State
会議状態向けのセッション開始プロトコル（SIP）イベントパッケージ
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
Abstract
概要
This document defines a conference event package for tightly coupled conferences using the Session Initiation Protocol (SIP) events framework, along with a data format used in notifications for this package. The conference package allows users to subscribe to a conference Uniform Resource Identifier (URI). Notifications are sent about changes in the membership of this conference and optionally about changes in the state of additional conference components.
このドキュメントでは、セッション開始プロトコル（SIP）イベントフレームワークを使用して、このパッケージの通知で使用されるデータ形式を使用して、緊密に結合した会議の会議イベントパッケージを定義します。会議パッケージを使用すると、ユーザーは会議のユニフォームリソース識別子（URI）を購読できます。この会議のメンバーシップの変更、およびオプションで追加の会議コンポーネントの状態の変更について通知が送信されます。
Table of Contents
目次
1. Introduction ....................................................4
2. Terminology .....................................................4
3. Conference Event Package ........................................4
3.1. Event Package Name .........................................5
3.2. Filtering ..................................................5
3.3. Subscription Duration ......................................5
3.4. NOTIFY Bodies ..............................................5
3.5. Notifier Processing of SUBSCRIBE Requests ..................6
3.6. Notifier Generation of NOTIFY Requests .....................6
3.7. Subscriber Processing of NOTIFY Requests ...................6
3.8. Handling of Forked Requests ................................7
3.9. Rate of Notifications ......................................7
3.10. State Agents ..............................................7
4. Conference Document .............................................7
4.1. Format .....................................................7
4.2. Namespace ..................................................7
4.3. Versioning .................................................8
4.4. Partial Notifications Mechanism ............................8
4.5. Element Keys ...............................................9
4.6. Constructing Coherent State Procedure ......................9
5. Conference Data ................................................11
5.1. Overview ..................................................11
5.2. <conference-info> .........................................13
5.3. <conference-description> ..................................14
5.3.1. <conf-uris> ........................................14
5.3.2. <service-uris> .....................................15
5.3.3. <maximum-user-count> ...............................16
5.3.4. <available-media> ..................................16
5.4. <host-info> ...............................................17
5.4.1. <display-text> .....................................17
5.4.2. <web-page> .........................................17
5.4.3. <uris> .............................................17
5.5. <conference-state> ........................................17
5.5.1. <user-count> .......................................17
5.5.2. <active> ...........................................18
5.5.3. <locked> ...........................................18
5.6. <users> and Its <user> Sub-elements .......................18
5.6.1. <display-text> .....................................19
5.6.2. <associated-aors> ..................................19
5.6.3. <roles> ............................................19
5.6.4. <languages> ........................................19
5.6.5. <cascaded-focus> ...................................19
5.6.6. <endpoint> .........................................20
5.7. <endpoint> ................................................20
5.7.1. <display-text> .....................................20
5.7.2. <referred> .........................................21
5.7.3. <status> ...........................................21
5.7.4. <joining-method> ...................................22
5.7.5. <joining-info> .....................................23
5.7.6. <disconnection-method> .............................23
5.7.7. <disconnection-info> ...............................23
5.7.8. <media> ............................................24
5.7.9. <call-info> ........................................24
5.8. <media> ...................................................24
5.8.1. <display-text> .....................................25
5.8.2. <type> .............................................25
5.8.3. <label> ............................................25
5.8.4. <src-id> ...........................................25
5.8.5. <status> ...........................................26
5.9. Sidebars ..................................................26
5.9.1. <sidebars-by-ref> ..................................26
5.9.2. <sidebar-by-val> ...................................26
6. XML Schema .....................................................26
7. Examples .......................................................35
7.1. Basic Example .............................................35
7.2. Rich Example ..............................................36
8. Security Considerations ........................................40
8.1. Connection Security .......................................40
8.2. Authorization Considerations ..............................41
9. IANA Considerations ............................................41
9.1. conference Event Package Registration .....................41
9.2. application/conference-info+xml MIME Registration .........42
9.3. URN Sub-Namespace Registration for ........................43
9.4. XML Schema Registration ...................................43
9.5. URI Purposes Sub-registry Establishment ...................44
10. Acknowledgements ..............................................45
11. References ....................................................45
11.1. Normative References .....................................45
11.2. Informative References ...................................46
The Session Initiation Protocol (SIP) events framework [10] defines general mechanisms for subscribing to, and receiving notifications of, events within SIP networks. It introduces the notion of a package, which is a specific "instantiation" of the events framework for a well-defined set of events. Here, we define a SIP event package for tightly coupled conferences. This package can be used by the conference notification service as outlined in the SIP conferencing framework [16]. As described there, subscriptions to a conference URI are routed to the focus that is handling the conference. It acts as the notifier and provides clients with updates on conference state.
セッション開始プロトコル（SIP）イベントフレームワーク[10]は、SIPネットワーク内のイベントを購読および受信するための一般的なメカニズムを定義します。それは、明確に定義された一連のイベントのためのイベントフレームワークの特定の「インスタンス化」であるパッケージの概念を紹介します。ここでは、緊密に結合した会議のためのSIPイベントパッケージを定義します。このパッケージは、SIP会議のフレームワークで概説されているように、会議通知サービスで使用できます[16]。そこに記載されているように、会議URIのサブスクリプションは、会議を処理する焦点にルーティングされています。それはnotifierとして機能し、クライアントに会議状態の更新を提供します。
The information provided by this package is comprised of conference identifier(s), conference participants (optionally with their statuses and media description), conference sidebars, conference service URIs, etc.
このパッケージが提供する情報は、会議識別子、会議参加者（オプションではステータスとメディアの説明を含む）、会議のサイドバー、会議サービスURIなどで構成されています。
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 [1] and indicate requirement levels for compliant implementations.
このドキュメントでは、キーワードが「必須」、「必須」、「必須」、「shall」、「shall "、" low "of" bould "、" becommented "、"、 "、"、 "optional"RFC 2119 [1]に記載されているように解釈され、準拠した実装の要件レベルを示します。
This document uses the conferencing terminology defined in Conferencing Framework [16]. In addition, the "roster" term is used to collectively refer to participants in a conference or a sub-conference.
このドキュメントでは、会議フレームワークで定義された会議用語[16]を使用しています。さらに、「名簿」の用語は、会議またはサブカンファレンスの参加者を集合的に参照するために使用されます。
The conference event package allows a user to subscribe to the information relating to a conference. In SIP, conferences are represented by URIs. These URIs identify a SIP user agent (UA), called a focus, that is responsible for ensuring that all users in the conference can communicate with each other, as described in Conferencing Framework [16]. The focus has sufficient information about the state of the conference to inform subscribers about it.
会議イベントパッケージを使用すると、ユーザーは会議に関連する情報を購読できます。SIPでは、会議はURISによって表されます。これらのURIは、焦点と呼ばれるSIPユーザーエージェント（UA）を特定します。これは、会議のすべてのユーザーが互いに通信できるようにする責任があります。焦点には、会議の状態に関する十分な情報があり、加入者にそれについて通知します。
It is possible that a participant in the conference may in fact be another focus. In order to provide a more complete participant list, the focus MAY subscribe to the conference package of the other focus to discover the participant list in the cascaded conference. This information can then be included in notifications by use of the <cascaded-focus> element as specified by this package.
会議の参加者が実際に別の焦点である可能性があります。より完全な参加者リストを提供するために、焦点は、カスケード会議の参加者リストを発見するために、他の焦点の会議パッケージを購読する場合があります。この情報は、このパッケージで指定されているように、<cascaded-focus>要素を使用して通知に含めることができます。
This section provides the details for defining a SIP-specific event notification package, as specified by RFC 3265 [10].
このセクションでは、RFC 3265 [10]で指定されているように、SIP固有のイベント通知パッケージを定義するための詳細を説明します。
The name of this event package is "conference". This package name is carried in the Event and Allow-Events header, as defined in RFC 3265 [10].
このイベントパッケージの名前は「会議」です。このパッケージ名は、RFC 3265 [10]で定義されているイベントヘッダーとAllow-Ieventsヘッダーに掲載されています。
Filters, which can be applied to conference subscriptions, are a desirable feature and can be considered as a subject of future standardization activities. This document does not define the filters for the conference package to be included in the SUBSCRIBE body.
会議サブスクリプションに適用できるフィルターは、望ましい機能であり、将来の標準化活動の対象と見なすことができます。このドキュメントでは、サブスクライブボディに含まれる会議パッケージのフィルターは定義されていません。
A SUBSCRIBE for a conference package, being sent without a body, implies the default subscription filtering policy. The default policy is as follows:
ボディなしで送信される会議パッケージの購読は、デフォルトのサブスクリプションフィルタリングポリシーを意味します。デフォルトのポリシーは次のとおりです。
o Notifications are generated every time there is any change in the state of the conference.
o 会議の状態に変更があるたびに通知が生成されます。
o Notifications do not normally contain full state; rather, they only indicate the state that has changed. The exception is a NOTIFY sent in response to a SUBSCRIBE. These NOTIFYs contain the full state of the information requested by the subscriber.
o 通知には通常、完全な状態が含まれていません。むしろ、彼らは変化した状態のみを示しています。例外は、購読に応じて送信された通知です。これらの通知には、サブスクライバーが要求した情報の完全な状態が含まれています。
The default expiration time for a subscription to a conference is one hour. Once the conference ends, all subscriptions to that particular conference are terminated, with a reason of "noresource" as defined in RFC 3265 [10].
会議のサブスクリプションのデフォルトの有効期限は1時間です。会議が終了すると、RFC 3265 [10]で定義されている「noresource」の理由があるため、その特定の会議のすべてのサブスクリプションが終了します。
According to RFC 3265 [10], the NOTIFY message will contain bodies that describe the state of the subscribed resource. This body is in a format listed in the Accept header field of the SUBSCRIBE, or a package-specific default if the Accept header field was omitted from the SUBSCRIBE.
RFC 3265 [10]によると、Notifyメッセージには、購読されたリソースの状態を記述するボディが含まれます。この本体は、サブスクライブの承認ヘッダーフィールドにリストされている形式、またはサブスクライブから承認ヘッダーフィールドが省略された場合、パッケージ固有のデフォルトです。
In this event package, the body of the notification contains a conference information document that describes the state of a conference. All subscribers and notifiers MUST support the "application/conference-info+xml" data format described in Sections 9 and 5. By default, i.e., if no Accept header is specified to a SUBSCRIBE request, the NOTIFY will contain a body in the "application/conference-info+xml" data format. If the Accept header field is present, it MUST include "application/conference-info+xml" and MAY include any other types.
このイベントパッケージでは、通知の本文には、会議の状態を説明する会議情報文書が含まれています。すべてのサブスクライバーと通知者は、セクション9および5で説明されている「アプリケーション/Conference-INFO XML」データ形式をサポートする必要があります。デフォルトでは、つまり、サブスクライブリクエストに受け入れヘッダーが指定されていない場合、Notifyには「アプリケーション」にボディが含まれます。/Conference-INFO XML "データ形式。受け入れヘッダーフィールドが存在する場合、「アプリケーション/Conference-INFO XML」を含め、他のタイプを含める必要があります。
The conference information contains very sensitive information. Therefore, all subscriptions SHOULD be authenticated and then authorized before approval. Authorization policy is at the discretion of the administrator, as always.
会議情報には非常に機密情報が含まれています。したがって、すべてのサブスクリプションは認証され、承認前に承認される必要があります。許可ポリシーは、いつものように、管理者の裁量にあります。
However, it is RECOMMENDED that all users in the conference be allowed to subscribe to the conference event package.
ただし、会議のすべてのユーザーをカンファレンスイベントパッケージに購読することを許可することをお勧めします。
Notifications SHOULD be generated for the conference state when a new participant joins (i.e., gets "connected" to) or a participant leaves (i.e., gets "disconnected" from) the conference.
新しい参加者が参加し（つまり、「接続」する）、または参加者が会議を去る（つまり、「切断」される）ときの会議状態に対して通知を生成する必要があります。
Subject to a local focus policy, additional changes in participants' status, changes in their media types, and other optional information MAY be reported by the focus.
ローカルフォーカスポリシーに従い、参加者のステータスの追加の変更、メディアタイプの変更、およびその他のオプション情報が焦点によって報告される場合があります。
Changes in sidebar rosters SHOULD be reported by the focus to their participants and MAY be reported to others, subject to local policy.
サイドバー名簿の変更は、参加者に焦点を当てることによって報告されるべきであり、現地のポリシーに従って他の人に報告される場合があります。
Changes in conference identifiers and service URIs SHOULD be reported by the focus to the conference package subscribers.
会議の識別子とサービスURIの変更は、会議パッケージの加入者に焦点を当てて報告する必要があります。
Changes in other conference state information MAY be reported by the focus to the conference package subscribers.
他の会議の状態情報の変更は、会議パッケージの加入者に焦点を当てることによって報告される場合があります。
The SIP events framework expects packages to specify how a subscriber processes NOTIFY requests in any package-specific ways, and in particular, how it uses the NOTIFY requests to construct a coherent view of the state of the subscribed resource.
SIPイベントフレームワークでは、パッケージがパッケージ固有の方法でサブスクライバープロセスがリクエストを通知する方法、特に通知要求を使用してサブスクライブリソースの状態のコヒーレントビューを構築する方法を指定することを期待しています。
Typically, the NOTIFY for the conference package will only contain information about those users whose state in the conference has changed. To construct a coherent view of the total state of all users, a subscriber to the conference package will need to combine NOTIFYs received over time.
通常、会議パッケージの通知には、会議の状態が変更されたユーザーに関する情報のみが含まれます。すべてのユーザーの合計状態の一貫したビューを構築するには、会議パッケージのサブスクライバーを長期にわたって受信した通知を組み合わせる必要があります。
Notifications within this package can convey partial information; that is, they can indicate information about a subset of the state associated with the subscription. This means that an explicit algorithm needs to be defined in order to construct coherent and consistent state. The details of this mechanism are specific to the particular document type. See Section 4.6 for information on constructing coherent information from an application/ conference-info+xml document.
このパッケージ内の通知は、部分的な情報を伝えることができます。つまり、サブスクリプションに関連する状態のサブセットに関する情報を示すことができます。これは、コヒーレントで一貫した状態を構築するために、明示的なアルゴリズムを定義する必要があることを意味します。このメカニズムの詳細は、特定のドキュメントタイプに固有です。Application/ Conference-INFO XMLドキュメントから一貫した情報の作成については、セクション4.6を参照してください。
By their nature, the conferences supported by this package are centralized. Therefore, SUBSCRIBE requests for a conference should not generally fork. If forking happens in the network, subscribers to this package MUST NOT establish more than a single SIP dialog as a result of a single SUBSCRIBE request. In the foci cascading case, detailed conference information can be retrieved by establishing an individual SUBSCRIBE dialog with each participating focus.
その性質上、このパッケージによってサポートされている会議は集中化されています。したがって、会議のサブスクライブリクエストは、一般的にフォークしてはなりません。ネットワークでフォーキングが発生した場合、このパッケージのサブスクライバーは、単一のサブスクライブリクエストの結果として、単一のSIPダイアログ以上を確立してはなりません。Foci Cascadingケースでは、各参加焦点で個々の購読ダイアログを確立することにより、詳細な会議情報を取得できます。
For reasons of congestion control, it is important that the rate of notifications not become excessive. As a result, it is RECOMMENDED that the server does not generate notifications for a single subscriber at a rate faster than once every 5 seconds.
混雑制御の理由により、通知率が過剰にならないことが重要です。その結果、サーバーは、5秒ごとに1回よりも速いレートで単一のサブスクライバーの通知を生成しないことをお勧めします。
Conference state is ideally maintained in the element in which the conference resides. Therefore, a conference focus is the best-suited element to handle subscriptions to it. Cascaded foci MAY implement state agents (as defined in RFC 3265 [10]) for this package.
会議の状態は、会議が存在する要素で理想的に維持されます。したがって、会議の焦点は、サブスクリプションを処理するのに最適な要素です。このパッケージには、CASCADEDフォーカスが状態エージェント（RFC 3265 [10]で定義されている）を実装する場合があります。
Conference information is an XML document that MUST be well-formed and valid. It MUST be based on Extensible Markup Language (XML) 1.0 and MUST be encoded using UTF-8 [14].
会議情報はXMLドキュメントであり、適切に形成され、有効でなければなりません。拡張可能なマークアップ言語（XML）1.0に基づいている必要があり、UTF-8 [14]を使用してエンコードする必要があります。
This specification makes use of XML namespaces for identifying conference information documents and document fragments. The namespace URI for elements defined by this specification is a Uniform Resource Namespace (URN) [2], using the namespace identifier 'ietf' defined by [6] and extended by RFC 3688 [21]. This URN is as follows:
この仕様では、会議の情報文書を識別し、断片を文書化するためにXMLネームスペースを使用します。この仕様で定義された要素の名前空間URIは、[6]で定義され、RFC 3688 [21]によって拡張された名前空間識別子「IETF」を使用して、均一なリソース名空間（URN）[2]です。このurnは次のとおりです。
urn:ietf:params:xml:ns:conference-info
The conference information is described by a hierarchical XML structure with the root element <conference-info>. The root element is the only element in the schema that carries a meaningful version number for all the elements in the document. The whole conference information is associated with this version number.
会議情報は、ルート要素<Conference-Info>を使用した階層XML構造によって説明されています。ルート要素は、ドキュメント内のすべての要素に対して意味のあるバージョン番号を持つスキーマの唯一の要素です。会議全体の情報は、このバージョン番号に関連付けられています。
The 'version' attribute MUST be included in the root <conference-info> element.
「バージョン」属性は、root <Conference-info>要素に含める必要があります。
This specification defines a basic partial notifications mechanism by using a 'state' attribute as described below. This mechanism MUST be supported by all subscribing clients. Additional general partial notifications mechanisms can be defined and applied to this package in the future.
この仕様は、以下に説明する「状態」属性を使用することにより、基本的な部分通知メカニズムを定義します。このメカニズムは、すべての購読クライアントによってサポートされる必要があります。追加の一般的な部分通知メカニズムを定義し、将来このパッケージに適用できます。
All sub-elements in the <conference-info> hierarchical XML structure can be classified in two groups: permissible for partial notifications or not. Elements that carry a substantial amount of data that is subject to frequent changes are permissible for partial notifications and have a 'state' attribute attached to them. All future extensions to this schema MUST define which extension elements can also use this mechanism. All other elements can be updated as atomic pieces of data only.
<Conference-Info>階層XML構造のすべてのサブ要素は、部分的な通知に許容できる2つのグループに分類できます。頻繁な変更の対象となるかなりの量のデータを運ぶ要素は、部分的な通知で許可され、それらに「状態」属性が付属しています。このスキーマの将来の拡張はすべて、このメカニズムを使用できる拡張要素を定義する必要があります。他のすべての要素は、アトミックのデータのみとして更新できます。
Below is the complete list of elements permissible to use the partial notifications mechanism defined in this specification. (Note that future partial notifications mechanisms can potentially be applicable to additional elements.)
以下は、この仕様で定義されている部分的な通知メカニズムを使用することが許容される要素の完全なリストです。（将来の部分通知メカニズムは、追加の要素に適用できる可能性があることに注意してください。）
o Element <conference-info> o Element <users> o Element <user> o Element <endpoint> o Element <sidebars-by-val> o Element <sidebars-by-ref> The 'state' attribute value indicates whether the reported information about the element is "full" or "partial", or whether the element has been "deleted" from the conference state document. The default value of any 'state' attribute is "full".
o 要素<Conference-INFO> o要素<ユーザー> o要素<ユーザー> o要素<Endpoint> o要素<sidebars-by-val> o要素<sidebars-by-ref> 'state'属性値は、報告された情報が報告されているかどうかを示します要素については、「完全」または「部分的」、または会議の状態文書から要素が「削除された」かどうかです。「状態」属性のデフォルト値は「完全」です。
A 'state' attribute of a child element in the document MUST be consistent with its parent 'state'. This means that if the parent's 'state' is "full", the state of its children MUST be "full". If the parent's 'state' is "partial", the state of its children MAY be either "partial", "full", or "deleted". A parent element with "deleted" 'state' SHOULD NOT contain child elements. Any information provided for child elements of a "deleted" parent MUST be ignored by the package subscriber.
ドキュメント内の子要素の「状態」属性は、その親「状態」と一致する必要があります。これは、親の「状態」が「完全」である場合、子供の状態は「完全」でなければならないことを意味します。親の「状態」が「部分的」である場合、子供の状態は「部分的」、「完全」、または「削除」のいずれかです。「削除された」「状態」を持つ親要素には、子要素を含めるべきではありません。「削除された」親の子要素に提供される情報は、パッケージサブスクライバーによって無視する必要があります。
The defined XML schema has a property of unique identification among sub-elements of a common parent, which makes it possible to use the partial notifications mechanism defined in this document. This property is achieved by defining a key to each sub-element that can appear multiple times under the common parent.
定義されたXMLスキーマには、共通の親のサブエレメントの間に一意の識別の特性があり、このドキュメントで定義されている部分的な通知メカニズムを使用することが可能になります。このプロパティは、一般的な親の下に複数回表示される可能性のある各サブ要素のキーを定義することによって達成されます。
In the context of this specification, the element key is the set of mandatory attributes or sub-elements of an element. The key value MUST be unique for the element among its siblings of the same type.
この仕様のコンテキストでは、要素キーは、要素の必須属性またはサブエレメントのセットです。キー値は、同じタイプの兄弟の中の要素にとって一意でなければなりません。
In the context of this specification, two keys of type xs:anyURI are considered to be equal if the UTF-8 representations of the keys (including all URI parameters that can be included with the URI) are identical. Consequently, using relative URIs and lexical white space in these keys is NOT RECOMMENDED.
この仕様のコンテキストでは、タイプXSの2つのキー：Anyuriは、キーのUTF-8表現（URIに含めることができるすべてのURIパラメーターを含む）が同一である場合、等しいと見なされます。その結果、これらのキーに相対的なURIと語彙空白を使用することは推奨されません。
Below is the list of elements (subject to partial notifications of their parent elements) with their keys as defined by this specification:
以下は、この仕様で定義されているキーを使用した要素のリスト（親要素の部分的な通知の対象となります）です。
o Element <user> uses as the key 'entity' o Element <endpoint> uses as the key 'entity' o Element <media> uses as the key 'id' o Element <entry> (child to <sidebars-by-val>) uses as the key 'entity' o Element <sidebars-by-ref> uses as the key <uri>
o 要素<ユーザー>キー「エンティティ」o要素<Endpoint>を使用する<Endpoint>は、キー「エンティティ」として使用されますo要素<media>は、キー「ID」o要素<Entry>（child to <sidebars-by-val>として使用されます。）キー「エンティティ」として使用o要素<sidebars-by-ref>はキー<uri>として使用します
This section describes the algorithm for constructing a coherent conference state by a subscriber to the conference package. Using software programming abstraction, the subscriber maintains a single local version number for the whole conference document and a local element instance for each element in the schema. Also, for each element with keys (as defined above), the subscriber maintains a virtual table with a row for each existing key value.
このセクションでは、会議パッケージのサブスクライバーによる一貫した会議状態を構築するためのアルゴリズムについて説明します。ソフトウェアプログラミングの抽象化を使用して、サブスクライバーは、会議ドキュメント全体に単一のローカルバージョン番号とスキーマ内の各要素のローカル要素インスタンスを維持します。また、キーを持つ各要素（上記で定義）について、サブスクライバーは、既存のキー値ごとに行を持つ仮想テーブルを維持します。
The first time a NOTIFY with a "full" document is received (as indicated by the value of the 'state' attribute in the <conference-info> element), the conference package subscriber MUST set the local 'version' number to the value of the 'version' attribute from the received <conference-info> and populate local data with the received information.
「完全な」ドキュメントを使用した通知が初めて（<Conference-info>要素の「状態」属性の値で示されるように）、会議パッケージサブスクライバーは、ローカル「バージョン」番号を値に設定する必要があります。受信した<Somention-Info>からの「バージョン」属性の属性と、受信した情報にローカルデータを入力します。
Each time a new NOTIFY is received, the value of the local version number and the value of the 'version' attribute in the new received document are compared. If the value in the document is equal to or less than the local version, the document is discarded without processing.
新しいNotifyが受信されるたびに、新しい受信ドキュメントのローカルバージョン番号の値と「バージョン」属性の値が比較されます。ドキュメントの値がローカルバージョン以下の場合、ドキュメントは処理せずに破棄されます。
Otherwise, if the received NOTIFY contains a "full" or "deleted" state, the conference package subscriber MUST set the local 'version' number to the value of the 'version' attribute from the received <conference-info> and replace the local information with the received document. Receiving "deleted" state for the <conference-info> element means that the conference has ceased to exist and the subscriber SHOULD terminate the subscription by sending the SUBSCRIBE with Expires = 0.
それ以外の場合、受信したNotifyに「完全」または「削除された」状態が含まれている場合、会議パッケージサブスクライバーは、受信<Conference-INFO>から「バージョン」属性の値にローカル「バージョン」番号を設定し、ローカルを置き換える必要があります。受け取ったドキュメントを含む情報。<Conference-Info>要素の「削除」状態を受信することは、会議が存在しなくなり、サブスクライバーが期限切れ= 0でサブスクライブを送信してサブスクリプションを終了することを意味します。
Otherwise (i.e., if the received NOTIFY contains "partial" state), if the 'version' number in the received document is more than one number higher than the previous local version number, the subscriber MUST generate a subscription refresh request to trigger a full state notification. If the 'version' number in the document is one higher than the local version number, the local version number is updated accordingly and the document is used to update the local content as described below.
それ以外の場合は（つまり、受信した通知に「部分的な」状態が含まれている場合）、受信ドキュメントの「バージョン」番号が以前のローカルバージョン番号よりも複数の数字が多い場合、サブスクライバーはサブスクリプションリクエストを生成して完全なものをトリガーする必要があります。状態通知。ドキュメントの「バージョン」番号がローカルバージョン番号よりも高い場合、ローカルバージョン番号はそれに応じて更新され、ドキュメントは以下に説明するようにローカルコンテンツを更新するために使用されます。
For each sub-element of the <conference-info> element in the received document,
受信したドキュメントの<Conference-Info>要素のサブ要素ごとに、
1. If the element contains "full" state, the whole local element content is flushed and repopulated from the document.
1. 要素に「完全な」状態が含まれている場合、ローカル要素のコンテンツ全体がフラッシュされ、ドキュメントから再貯蔵されます。
2. Otherwise, if the element contains "deleted" state, the whole element MUST be removed from the local content.
2. それ以外の場合、要素に「削除された」状態が含まれている場合、要素全体をローカルコンテンツから削除する必要があります。
3. Otherwise, if the element contains "partial" state:
3. それ以外の場合、要素に「部分的な」状態が含まれている場合：
3.1. For elements with keys, the subscriber compares the keys received in the update with the keys in the local tables.
3.1. キーを備えた要素の場合、サブスクライバーは、更新で受信したキーをローカルテーブルのキーと比較します。
3.1.1. If a key does not exist in the local table, a row is added, and its content is set to the element information from the update.
3.1.1. キーがローカルテーブルに存在しない場合、行が追加され、そのコンテンツはアップデートの要素情報に設定されます。
3.1.2. Otherwise, if a key of the same value does exist, for each sub-element in the row, the algorithm is applied from step 3.2.
3.1.2. それ以外の場合、同じ値のキーが存在する場合、行のサブ要素ごとに、アルゴリズムがステップ3.2から適用されます。
3.2. For each atomic element received in the schema, the element is replaced with the new information as a whole. For each non-atomic element received in the schema with either no 'state' attribute included or the state attribute is set to "full", the element is replaced with the new information as a whole. Also, for each element with the state attribute set to "deleted", the whole element is removed from the local content.
3.2. スキーマで受信した各原子要素について、要素は新しい情報全体に置き換えられます。「状態」属性が含まれていない、または状態属性が「完全」に設定されているスキーマで受信された非原子要素ごとに、要素は新しい情報全体に置き換えられます。また、状態属性が「削除」に設定された各要素について、要素全体がローカルコンテンツから削除されます。
3.3. For each non-atomic element with the state attribute set to "partial", the algorithm is applied recursively starting from step 3.1.
3.3. 状態属性を「部分」に設定した各非原子要素について、アルゴリズムはステップ3.1から再帰的に適用されます。
The <conference-info> document format is designed to convey information about the conference and about participation in the conference. The following non-normative diagram gives an example of the overall hierarchy used in this format. Conferences contain users who can be represented by multiple endpoints, each of which can have multiple media streams. Conferences can also include or reference "sidebar conferences". When sidebar information is incorporated into a conference information document in a <sidebars-by-val> element, each <entry> element represents a sidebar and can include any sub-elements permitted in the <conference-info> top-level element.
<Conference-info>ドキュメント形式は、会議に関する情報と会議への参加に関する情報を伝えるように設計されています。次の非規範的図は、この形式で使用されている全体的な階層の例を示しています。会議には、複数のエンドポイントで表現できるユーザーが含まれており、それぞれに複数のメディアストリームがあります。会議には、「サイドバー会議」を参照することもできます。サイドバー情報が<sidebar-by-val>要素の会議情報ドキュメントに組み込まれている場合、各<エントリ>要素はサイドバーを表し、<Conference-INFO>トップレベル要素に許可されているサブ要素を含めることができます。
conference-info
|
|-- conference-description
|
|-- host-info
|
|-- conference-state
|
|-- users
| |-- user
| | |-- endpoint
| | | |-- media
| | | |-- media
| | | |-- call-info
| | |
| | |-- endpoint
| | |-- media
| |-- user
| |-- endpoint
| |-- media
|
|-- sidebars-by-ref
| |-- entry
| |-- entry
|
|-- sidebars-by-val
|-- entry
| |-- users
| |-- user
| |-- user
|-- entry
|-- users
|-- user
|-- user
|-- user
In most cases, this document does not mandate how the information, presented through the conference document to the subscribers, is obtained by the focus. In many cases, the information can be dynamically learned from the call signaling and can also be manually populated by an administrator - all subject to local policies. This document specifies what the XML elements mean in order to allow the subscribers to appropriately interpret it. Some portions of the information are intended for processing by automata; others are for human consumption only. For example, the <display-text> sub-elements of elements <conf-uris>, <service-uris>, <available-media>,
ほとんどの場合、この文書は、会議文書を通じてサブスクライバーに提示された情報が焦点によって取得される方法を義務付けていません。多くの場合、情報はコールシグナリングから動的に学習することができ、すべてのローカルポリシーの対象となる管理者が手動で入力することもできます。このドキュメントは、サブスクライバーが適切に解釈できるようにするために、XML要素の意味を指定します。情報の一部は、オートマトンによる処理を目的としています。その他は人間の消費のみです。たとえば、要素の<ディスプレイテキスト>サブエレメント<conf-uris>、<service-uris>、<abawal-media>、
<host-info>, <endpoint>, and <media> are intended for display to human subscribers only.
<HOST-INFO>、<EndPoint>、および<media>は、人間の加入者のみに表示することを目的としています。
Although in multiple places this document states that specific information "SHOULD" be communicated to the subscribers, note that particular conference package subscribers (e.g., representing a moderator, an administrator, or a cascaded focus) rely on accuracy of this information for their proper operation. Therefore, a conferencing server MUST ensure that all critical changes (stated as "SHOULD") are communicated to these specific subscribers; otherwise, these changes MUST be communicated to all subscribers to the conference information.
複数の場所では、特定の情報をサブスクライバーに「」伝える必要があると述べていますが、特定の会議パッケージサブスクライバー（例えば、モデレーター、管理者、またはカスケード焦点を表す）は、適切な操作のためにこの情報の正確性に依存していることに注意してください。。したがって、会議サーバーは、これらの特定のサブスクライバーにすべての重要な変更（「必須」と記載されている）が伝えられるようにする必要があります。それ以外の場合、これらの変更は、会議情報のすべてのサブスクライバーに伝える必要があります。
Following sections describe the XML schema in more detail.
次のセクションでは、XMLスキーマについて詳しく説明します。
A conference information document begins with the root element tag <conference-info> of conference-type.
会議情報ドキュメントは、Conference-TypeのRoot Element Tag <Conference-Info>で始まります。
The following attributes are defined for <conference-info>:
次の属性は、<Conference-info>で定義されています。
entity: This attribute contains the conference URI that identifies the conference being described in the document. This is the SIP URI that an interested entity needs to SUBSCRIBE to in order to get the conference package information. Note that this URI can be listed as one of the URIs to be used in order to access the conference by SIP means and in accordance with Section 5.3.1 below.
エンティティ：この属性には、ドキュメントに記載されている会議を識別する会議URIが含まれています。これは、関心のあるエンティティが会議パッケージ情報を取得するために購読する必要があるSIP URIです。このURIは、以下のセクション5.3.1に従って、SIP手段で会議にアクセスするために使用するURIの1つとしてリストできることに注意してください。
state: This attribute indicates whether the document contains the whole conference information ("full") or only the information that has changed since the previous document ("partial"), or whether the conference ceased to exist ("deleted"). For more detail, see Section 4.
状態：この属性は、ドキュメントに会議情報全体（「フル」）全体が含まれているのか、それとも前のドキュメント（「部分的」）以降に変更された情報のみを示しているのか、それとも会議が存在しなくなった（「削除」）。詳細については、セクション4を参照してください。
version: This attribute allows the recipient of conference information documents to properly order the received notifications, and it MUST be used with the root <conference-info> element. Version number is a 32-bit monotonically increasing integer scoped within a subscription. A server MUST increment the version number for each notification (full, partial, and deleted) being sent to a subscriber and reporting a change in the conference document state. For each partial notification, the version number MUST be increased by one. Note that a partial notification and a subsequent full notification over the same dialog MAY contain the same version number if no change in the conference state occurred in between.
バージョン：この属性により、会議情報ドキュメントの受信者が受信された通知を適切に注文できるようになり、root <Conference-info>要素で使用する必要があります。バージョン番号は、サブスクリプション内でスコープされた32ビットの単調に増加する整数です。サーバーは、サブスクライバーに送信され、会議文書状態の変更を報告する各通知（フル、部分、削除）のバージョン番号をインクリメントする必要があります。部分通知ごとに、バージョン番号を1つずつ増やす必要があります。部分的な通知と同じダイアログ上のその後の完全な通知には、会議状態に変更が発生しなかった場合、同じバージョン番号が含まれる場合があることに注意してください。
The <conference-info> element is comprised of <conference-description>, <host-info>, <conference-state>, <users>, <sidebars-by-ref> and <sidebars-by-val> child elements. A "full" conference document MUST at least include the <conference-description> and <users> child elements.
<Conference-info>要素は、<Conference-description>、<host-info>、<Conference-state>、<users>、<sidebars-by-ref>、<sidebars-by-val>の要素で構成されています。「完全な」会議の文書には、少なくとも<Conference-Description>および<ユーザー>子要素を含める必要があります。
Following sections describe these elements in detail. The full XML schema is provided in Section 6.
次のセクションでは、これらの要素について詳しく説明します。完全なXMLスキーマはセクション6に記載されています。
The <conference-description> element describes the conference as a whole.
<Conference-Description>要素は、会議全体を説明しています。
The child elements <display-text>, <subject>, <free-text>, and <keywords> are used to describe the conference content:
子の要素<ディスプレイテキスト>、<taxpect>、<free-text>、および<keywords>は、会議のコンテンツを説明するために使用されます。
<display-text>: Contains descriptive text suitable for human consumption, for example, listing in a directory
<ディスプレイテキスト>：たとえば、ディレクトリにリストするなど、人間の消費に適した説明テキストが含まれています
<subject>: Contains the subject of the conference
<free-text>: Contains an additional longer description of the conference
<フリーテキスト>：会議のさらに長い説明が含まれています
<keywords>: Contains a list of space-separated string tokens that can be used by search engines to better classify the conference
<キーワード>：検索エンジンが使用して会議をより適切に分類できるスペース分離された文字列トークンのリストが含まれています
Additional child elements <conf-uris> and <service-uris> are used to describe the conference-related URIs; <maximum-user-count> and <available-media> are used to describe the overall characteristics.
追加の子要素<conf-uris>および<Service-uris>は、会議関連のURIを説明するために使用されます。<maxim-user-count>および<available-media>は、全体的な特性を記述するために使用されます。
This information is typically derived from the system conference policies, is set before the conference activation, and is rarely changed during the conference lifetime.
この情報は通常、システム会議のポリシーから導き出され、会議のアクティブ化の前に設定され、会議の寿命の間にめったに変更されません。
The following sections describe the remaining elements in more detail. Other sub-elements can extend <conference-description> in the future.
次のセクションでは、残りの要素についてさらに詳しく説明します。他のサブ要素は、将来<Conference-Description>を拡張できます。
This element contains a sequence of <entry> child elements - each containing the URI to be used in order to access the conference by different signaling means. The value of the URI MUST be unique in the conference context and is included in the <uri> sub-element.
この要素には、異なるシグナル伝達平均で会議にアクセスするために使用するURIを含む<エントリ>子要素のシーケンスが含まれています。URIの価値は、会議の文脈で一意でなければならず、<uri>サブ要素に含まれています。
Each <entry> MAY contain additional information useful to the participant when accessing the conference.
各<エントリ>には、会議にアクセスする際に参加者に役立つ追加情報が含まれる場合があります。
An <entry> element MAY contain the <display-text> sub-element that provides a textual description meant for human consumption.
<Entry>要素には、人間の消費向けのテキスト説明を提供する<display-text>サブエレメントが含まれる場合があります。
Each <entry> element SHOULD contain a <purpose> sub-element that describes what happens when accessing the URI. The currently defined <purpose> values to be used with the <conf-uris> are the following:
各<エントリ>要素には、URIにアクセスするときに何が起こるかを説明する<目的>サブ要素を含める必要があります。<conf-uris>で使用される現在定義されている<目的>値は次のとおりです。
participation: Accessing a URI with this <purpose> will bring the party into the conference.
参加：この<目的でURIにアクセスすると、パーティーが会議に参加します。
streaming: Accessing a URI with this <purpose> will commence streaming the conference, but not allow active participation.
ストリーミング：この<目的でURIへのアクセスは、会議のストリーミングを開始しますが、積極的な参加を許可しません。
Examples of suitable URI schemes include sip: and sips: [8], xmpp: [22], h323: [20], and tel: [19] URIs. The rtsp [18] URI is suitable for streaming.
適切なURIスキームの例には、SIP：およびSIP：[8]、XMPP：[22]、H323：[20]、およびTel：[19] URISが含まれます。RTSP [18] URIは、ストリーミングに適しています。
Future extensions to this schema may define new values and register them with IANA under the registry established by this specification.
このスキーマの将来の拡張は、新しい値を定義し、この仕様によって確立されたレジストリの下でIANAに登録する場合があります。
This element describes auxiliary services available for the conference. Like <conference-uris>, this element contains a set of <entry> child elements - each containing the URI to be used in order to access different services available for the particular conference. The value of the URI MUST be unique in the conference context and is included in the <uri> sub-element.
この要素は、会議で利用可能な補助サービスについて説明しています。<conference -uris>のように、この要素には、特定の会議で利用可能なさまざまなサービスにアクセスするために使用されるURIを含む<エントリ>子要素のセットが含まれています。URIの価値は、会議の文脈で一意でなければならず、<uri>サブ要素に含まれています。
An <entry> element MAY contain the <display-text> sub-element that provides a textual description meant for user consumption.
<エントリ>要素には、ユーザー消費向けのテキスト説明を提供する<display-text>サブエレメントが含まれる場合があります。
Each <entry> element SHOULD contain a <purpose> sub-element. The currently defined <purpose> values to be used with the <service-uris> are the following:
各<エントリ>要素には、<目的>サブエレメントを含める必要があります。現在定義されている<Service-uris>で使用される<目的>値は次のとおりです。
web-page: Indicates the web page containing the additional information about the conference.
Webページ：会議に関する追加情報を含むWebページを示します。
recording: Indicates the link at which the recorded conference context can be retrieved.
録画：記録された会議のコンテキストを取得できるリンクを示します。
event: Indicates the URI at which a subscription to the conference event package may be requested. This would typically be the conference URI of the main conference.
イベント：会議イベントパッケージのサブスクリプションが要求されるURIを示します。これは通常、メインカンファレンスのカンファレンスURIになります。
Future extensions to this schema may define new values and register them with IANA under the registry established by this specification.
このスキーマの将来の拡張は、新しい値を定義し、この仕様によって確立されたレジストリの下でIANAに登録する場合があります。
The value of this element provides a hint to the recipient of the conference document about the number of users that can be invited to the conference. Typically, this value represents the overall number of users allowed to join the conference by different means as published through the conference document in <conf-uris>. Note that this value is set by an administrator and can reflect any local policies combination such as network consumption, CPU processing power, and licensing rules.
この要素の価値は、会議に招待できるユーザーの数に関する会議文書の受信者にヒントを提供します。通常、この値は、<conf-uris>の会議文書を通じて公開されているように、異なる手段で会議に参加することが許可されているユーザーの総数を表します。この値は管理者によって設定されており、ネットワーク消費、CPU処理能力、ライセンスルールなどのローカルポリシーの組み合わせを反映できることに注意してください。
This element contains a sequence of <entry> child elements of conference-medium-type, each being indexed by the attribute 'label'.
この要素には、Conference-Mediumタイプの<Entry>子要素のシーケンスが含まれており、それぞれが属性「ラベル」によってインデックス化されています。
The 'label' attribute is the media stream identifier assigned by the conferencing server: its value will be unique in the <conference-info> context. The value of this attribute will typically correspond to the Session Description Protocol (SDP) "label" media attribute defined in [17].
「ラベル」属性は、会議サーバーによって割り当てられたメディアストリーム識別子です。その値は、<Conference-info>コンテキストで一意になります。この属性の値は、通常、[17]で定義されているセッション説明プロトコル（SDP）「ラベル」メディア属性に対応します。
Each <entry> describes a single media stream available to the participants in the conference and contains the following information:
各<エントリ>は、会議の参加者が利用できる単一のメディアストリームについて説明し、次の情報を含みます。
<display-text>: This element contains the display text for the media stream.
<ディスプレイテキスト>：この要素には、メディアストリームの表示テキストが含まれています。
<type>: This element contains the media type of the media stream. The value of this element MUST be one of the values registered for "media" of SDP [3] and its later revision(s), for example, "audio", "video", "text", and "message".
<タイプ>：この要素には、メディアのメディアストリームのメディアタイプが含まれています。この要素の値は、SDP [3]の「メディア」に登録されている値の1つでなければなりません。たとえば、「オーディオ」、「ビデオ」、「テキスト」、「メッセージ」など、その後の改訂版です。
<status>: This element indicates the available status of the media stream available to the conference participants. For example, this would be the status of the media stream, which would be offered by the focus, in a 'dial-out' scenario. Using normal SIP offer/answer mechanisms (being defined in RFC 3264 [9]) in both dial-in and dial-out scenarios, a participant can of course establish only a subset of the available stream (i.e., request or accept the stream in one direction only, if both directions are available). The valid values are "sendrecv", "sendonly", "recvonly", or "inactive" as defined in SDP [3] and its later revision(s). (Note that the value specifies the direction from the participants' point of view.)
<ステータス>：この要素は、会議参加者が利用できるメディアストリームの利用可能なステータスを示しています。たとえば、これは「ダイヤルアウト」シナリオでフォーカスによって提供されるメディアストリームのステータスです。ダイヤルインとダイヤルアウトシナリオの両方で、通常のSIPオファー/回答メカニズム（RFC 3264 [9]で定義されている）を使用して、参加者はもちろん利用可能なストリームのサブセットのみを確立できます（つまり、ストリームを要求または受け入れることができます。両方の方向が利用可能な場合のみ一方向）。有効な値は、SDP [3]およびその後の改訂で定義されているように、「sendrecv」、「sendonly」、「recvonly」、または "inactive」です。（この値は、参加者の視点からの方向を指定することに注意してください。）
This element contains information about the entity hosting the conference. This information is set before the conference activation, and it is rarely changed during the conference lifetime, unless the whole conference is moved to be hosted by another entity. The host information is comprised of the following elements:
この要素には、会議をホストするエンティティに関する情報が含まれています。この情報は、会議のアクティブ化の前に設定されており、会議全体が別のエンティティによってホストされるように移動しない限り、会議寿命の間にめったに変更されません。ホスト情報は、次の要素で構成されています。
This element contains display text describing the entity hosting the conference.
この要素には、会議をホストするエンティティを説明するディスプレイテキストが含まれています。
This element contains HTTP: or HTTPS: URI of a web page describing either the conference service or the user hosting the conference.
この要素には、http：またはhttps：uri of of a webページがカンファレンスサービスまたは会議をホストするユーザーのいずれかを説明しています。
This element contains a set of <entry> child elements, each containing the URI value and optionally its description.
この要素には、それぞれがURI値とオプションでその説明を含む一連の<Entry>子要素が含まれています。
By including this element in the conference document, the server can inform the subscribers about the changes in the overall conference information. The <conference-state> child elements are described below.
この要素を会議文書に含めることにより、サーバーは、会議全体の情報の変更について加入者に通知できます。<Conference-State>子要素については、以下に説明します。
The value of this element tells the recipient of the conference document the overall number of users participating in the conference at a certain moment. Typically, this value represents the overall number of users who joined the conference by different means as published through the conference document in <conf-uris>. Note that this number does not necessarily need to match and MAY exceed the number of the entries in the <users> container. For example, in a lecturing scenario, large conference notifications may not include every participant in the <users> element, but instead report only the panelists or the speakers.
この要素の価値は、会議の受信者に、特定の瞬間に会議に参加するユーザーの総数を文書に伝えます。通常、この値は、<conf-uris>の会議文書を通じて公開されているように、異なる手段で会議に参加したユーザーの総数を表します。この数値は必ずしも一致する必要はなく、<ユーザー>コンテナのエントリの数を超える可能性があることに注意してください。たとえば、講義シナリオでは、大規模な会議通知には、<ユーザー>要素のすべての参加者が含まれるわけではなく、代わりにパネリストまたはスピーカーのみを報告する場合があります。
This Boolean element indicates whether the conference is currently active. A conference is active if calling one of the <conf-uris> by an authorized client results in successful establishment of a signaling session between the client and the focus and a successful joining of the conference.
このブール要素は、会議が現在アクティブであるかどうかを示します。承認されたクライアントによって<conf-uris>のいずれかを呼び出すと、クライアントと焦点の間のシグナリングセッションの確立が成功し、会議の参加が成功した場合、会議がアクティブになります。
This Boolean element says whether the conference is currently locked. In this context, "locked" means that the conference roster cannot be added to (although participants may leave or be removed from the conference).
このブールの要素には、会議が現在ロックされているかどうかがあります。この文脈では、「ロックされた」とは、会議の名簿を追加できないことを意味します（ただし、参加者は会議から去るか、削除される可能性があります）。
The <users> element is a container of <user> child elements, each describing a single participant in the conference.
<users>要素は、<ユーザー>子要素のコンテナであり、それぞれが会議の1人の参加者を説明しています。
The following attributes are defined for <user> element:
次の属性は、<ユーザー>要素に対して定義されています。
entity: This attribute contains the URI for the user in the conference. This is a logical identifier, which corresponds to the call signaling authenticated identity of the participant. The 'entity' value MUST be unique among all participants in the conference. If, for some participants, the focus decides not to reveal this information (e.g., due to local policies or security reasons), the host portion of the user URI MUST use the .invalid top level domain (TLD) according to definitions of RFC 2606 [5]. The focus also MUST construct the user portion of the URI so that the URI is unique among all participants of the same domain. For example, the convention
エンティティ：この属性には、会議のユーザーのURIが含まれています。これは論理的識別子であり、参加者の通話信号認証IDに対応します。「エンティティ」の価値は、会議のすべての参加者の中で一意でなければなりません。一部の参加者の場合、フォーカスがこの情報を明らかにしないことを決定した場合（たとえば、ローカルポリシーやセキュリティ上の理由により）、ユーザーURIのホスト部分は、RFC 2606の定義に従って.invalidトップレベルドメイン（TLD）を使用する必要があります。[5]。また、URIが同じドメインのすべての参加者の中でユニークになるように、URIのユーザー部分を構築する必要があります。たとえば、条約
"AnonymousX" <sip:anonymousX@anonymous.invalid>
SHOULD be used for a participant requesting privacy in accordance with the guidelines for generating anonymous URIs of RFC 3323 [11]. Note that in a different case, such as when used in conjunction with Enhancements for Authenticated Identity Management in SIP [25], the following convention can be used:
RFC 3323の匿名のURIを生成するためのガイドラインに従ってプライバシーを要求する参加者に使用する必要があります[11]。SIP [25]の認証されたアイデンティティ管理のための強化と組み合わせて使用する場合など、別のケースでは、次の規則を使用できます。
"AnonymousX" <sip:anonymousX@example.com>
state: This attribute indicates whether the document contains the whole user information ("full") or only the information that has changed since the previous document ("partial"), or whether the user was removed from the conference ("deleted").
状態：この属性は、ドキュメントにユーザー情報全体（「フル」）全体が含まれているか、以前のドキュメント（「部分的」）以降に変更された情報のみを含むか、またはユーザーが会議から削除された（「削除」）かどうかを示します。
The following child elements are defined for <user> element:
次の子要素は、<ユーザー>要素に対して定義されています。
This element is used to display the user-friendly name in the conference.
この要素は、会議にユーザーフレンドリーな名前を表示するために使用されます。
This element contains additional (to the 'entity') URIs being associated with the <user>. Typically, this information will be manually provided by an administrator showing the logical association between signaling entities otherwise independent. For example, if the 'entity' of a <user> contains a Globally Routable User URI (GRUU) [24] or tel: URI RFC 3966 [19], it would be useful to populate this field with the Address of Record (AOR) of the person who uses these devices, each represented as an independent <user>.
この要素には、<ユーザー>に関連付けられている追加の（「エンティティ」）が含まれています。通常、この情報は、それ以外の場合は独立したシグナリングエンティティ間の論理関連を示す管理者によって手動で提供されます。たとえば、A <user>の「エンティティ」にグローバルにルーティング可能なユーザーURI（Gruu）[24]またはTel：URI RFC 3966 [19]が含まれている場合、このフィールドにレコードのアドレス（AOR）を入力すると便利です。）これらのデバイスを使用する人のうち、それぞれが独立した<ユーザー>として表されます。
This element MAY contain a set of human-readable strings describing the roles of the user in the conference. Note that this information is applicable for human consumption only. This specification does not define the set of possible conferencing roles or the semantics associated with each. It is expected that future conferencing specifications will define these and the corresponding schema extensions, as appropriate.
この要素には、会議でのユーザーの役割を説明する人間の読み取り可能な文字列のセットが含まれている場合があります。この情報は、人間の消費のみに適用できることに注意してください。この仕様では、可能な会議の役割のセットやそれぞれに関連するセマンティクスを定義するものではありません。必要に応じて、将来の会議仕様がこれらと対応するスキーマ拡張機能を定義することが期待されています。
This element contains a list of tokens, separated by spaces, each containing a language understood by the user. This information can be automatically learned via call signaling or be manually set per participant.
この要素には、スペースで区切られたトークンのリストが含まれており、それぞれがユーザーが理解している言語を含んでいます。この情報は、通話信号を介して自動的に学習することも、参加者ごとに手動で設定することもできます。
This element contains a conference URI (different from the main conference URI) for users that are connected to the main conference as a result of focus cascading. In accordance with the SIP Conferencing Framework [16], this package allows for representation of peer-to-peer (i.e., "flat") focus cascading only. The actual cascading graph cannot be deduced from the information provided in the package alone. Advanced applications can construct the graph by subscribing to both this package and the Dialog Package [23] of each cascaded focus and correlating the relevant information.
この要素には、フォーカスカスケードの結果としてメインカンファレンスに接続されているユーザー向けのカンファレンスURI（メインカンファレンスURIとは異なります）が含まれています。SIP会議のフレームワーク[16]に従って、このパッケージでは、ピアツーピア（つまり、「フラット」）フォーカスカスケードのみを表現できます。実際のカスケードグラフは、パッケージだけで提供される情報から推測することはできません。高度なアプリケーションは、このパッケージと各カスケードフォーカスのダイアログパッケージ[23]の両方を購読し、関連情報を相関させることにより、グラフを構築できます。
By including one or more <endpoint> elements under a parent <user> element, the server can provide the desired level of detail (including the state, media streams, and access information) about the user's devices and signaling sessions taking part in the conference.
親<ユーザー>要素の下に1つ以上の<EndPoint>要素を含めることにより、サーバーは、ユーザーのデバイスとシグナリングセッションに関する詳細レベル（状態、メディアストリーム、アクセス情報を含む）を提供することができます。。
In a conferencing system where authentication is performed per endpoint (rather than per user), the focus can be unaware of the logical association of multiple endpoints under a common user. In this case, each endpoint will appear as a separate <user> with its own <endpoint> sub-element(s) in the conference document.
エンドポイントごとに認証が実行される会議システムでは（ユーザーごとではなく）、一般的なユーザーの下の複数のエンドポイントの論理的関連性に焦点が当てられない場合があります。この場合、各エンドポイントは、会議文書に独自の<EndPoint>サブ要素を含む別の<ユーザー>として表示されます。
In a different case, the focus may choose to shield the information about the participant's multiple endpoints and signaling sessions from other subscribers altogether (e.g., due to privacy policies). To do so, the focus MAY aggregate the multiple signaling sessions' information under a single <endpoint> element. Note that in this case, the detailed call signaling information (represented by <call-info> sub-element) will not be included.
別の場合、焦点は、他の加入者からの参加者の複数のエンドポイントとシグナルセッションに関する情報を完全に保護することを選択する場合があります（たとえば、プライバシーポリシーのため）。そのために、焦点は、単一の<EndPoint>要素の下に複数のシグナル伝達セッションの情報を集約する場合があります。この場合、詳細なコールシグナル伝達情報（<Call-Info>サブエレメントで表される）は含まれないことに注意してください。
This section describes the <endpoint> element in more detail.
このセクションでは、<EndPoint>要素について詳しく説明します。
The following attributes are defined for the <endpoint> element:
次の属性は、<EndPoint>要素に対して定義されています。
entity: The server MUST generate the 'entity' key for each <endpoint> element included under the parent <user>, such that its value is unique in the user context. In SIP terms, this can be the Contact URI, GRUU, etc.
エンティティ：サーバーは、親<ユーザー>の下に含まれる各<EndPoint>要素の「エンティティ」キーを生成する必要があります。そのため、その値はユーザーコンテキストで一意になります。SIPの用語では、これはURI、Gruuなどの連絡先になります。
state: This attribute indicates whether the element contains the whole endpoint information ("full") or only the information that has changed since the previous document ("partial"), or whether the endpoint has been removed from the conference ("deleted").
状態：この属性は、要素にエンドポイント情報全体（「フル」）全体が含まれているか、以前のドキュメント以降に変更された情報のみを示します（「部分的」）、またはエンドポイントが会議から削除された（「削除」）かどうかを示します。。
The following child elements are defined for the <endpoint> element:
次の子要素は、<EndPoint>要素に対して定義されています。
This element contains the display text for the endpoint.
この要素には、エンドポイントの表示テキストが含まれています。
This element contains information about the user whose action resulted in this endpoint being brought into the conference (e.g., the SIP user identified by this URI sent a REFER to the focus). It MAY contain the following sub-elements:
この要素には、このアクションがこのエンドポイントが会議に持ち込まれたユーザーに関する情報が含まれています（たとえば、このURIによって識別されたSIPユーザーが焦点を送信しました）。次のサブエレメントが含まれている場合があります。
when: This element of the XML dateTime type contains the date and time that the endpoint was referred to the conference and SHOULD be expressed in Coordinated Universal Time (UTC) format. For example,
いつ：XML DateTimeタイプのこの要素には、エンドポイントが会議に参照された日付と時刻が含まれており、調整されたユニバーサル時間（UTC）形式で表現する必要があります。例えば、
<when>2005-03-04T20:00:00Z</when>
reason: This element contains the reason the endpoint was referred to the conference. Including the information in the format defined by RFC 3326 [12] is RECOMMENDED. For example,
理由：この要素には、エンドポイントが会議に言及された理由が含まれています。RFC 3326 [12]で定義された形式の情報を含めることをお勧めします。例えば、
<reason>Reason: SIP;text="Ad-hoc Invitation"</reason>
by: This element contains the URI of the entity that caused the endpoint to be referred to the conference. In the case of SIP, it will be populated from the Referred-By header defined in RFC 3892 [15].
by：この要素には、エンドポイントを会議に紹介したエンティティのURIが含まれています。SIPの場合、RFC 3892 [15]で定義された参照ヘッダーから入力されます。
This element contains the status of the endpoint and can assume the following values:
この要素にはエンドポイントのステータスが含まれており、次の値を想定できます。
connected: The endpoint is a participant in the conference. Depending on the media policies, he/she can send and receive media to and from other participants.
接続：エンドポイントは会議の参加者です。メディアポリシーに応じて、彼/彼女は他の参加者にメディアを送信して受け取ることができます。
disconnected: The endpoint is not a participant in the conference, and no active dialog exists between the endpoint and the focus.
切断：エンドポイントは会議への参加者ではなく、エンドポイントとフォーカスの間にアクティブなダイアログは存在しません。
on-hold: Active signaling dialog exists between an endpoint and a focus, but endpoint is "on-hold" for this conference, i.e., he/she is neither "hearing" the conference mix nor is his/her media being mixed in the conference. As an example, the endpoint has asked to join the conference using SIP, but his/her participation is pending based on moderator approval. In the meantime, he/she is hearing music-on-hold or some other kind of related content.
オンホールド：エンドポイントとフォーカスの間にアクティブなシグナリングダイアログが存在しますが、エンドポイントはこの会議の「オンホールド」です。会議。例として、エンドポイントはSIPを使用して会議に参加するように求められていますが、彼/彼女の参加は、モデレーターの承認に基づいて保留されています。それまでの間、彼/彼女は音楽オンホールドまたは他の種類の関連コンテンツを聞いています。
muted-via-focus: Active signaling dialog exists between an endpoint and a focus and the endpoint can "listen" to the conference, but the endpoint's media is not being mixed into the conference. Note that sometimes a subset of endpoint media streams can be muted by focus (such as poor-quality video) while others (such as voice or IM) can still be active. In this case, it is RECOMMENDED that the "aggregated" endpoint connectivity <status> reflects the status of the most active media.
Muted-Via-Focus：エンドポイントとフォーカスの間にアクティブなシグナル伝達ダイアログが存在し、エンドポイントは会議を「聞く」ことができますが、エンドポイントのメディアは会議に混在していません。エンドポイントメディアストリームのサブセットは、フォーカス（低品質のビデオなど）によってミュートされることがあり、他のもの（音声やIMなど）はまだアクティブであることがあることに注意してください。この場合、「集計された」エンドポイント接続<ステータス>が最もアクティブなメディアのステータスを反映することをお勧めします。
pending: Endpoint is not yet in the session, but it is anticipated that he/she will join in the near future.
保留中：エンドポイントはまだセッションではありませんが、近い将来に彼/彼女が参加することが予想されます。
alerting: A Public Switched Telephone Network (PSTN) ALERTING or SIP 180 Ringing was returned for the outbound call; endpoint is being alerted.
アラート：公開された電話ネットワーク（PSTN）アランスまたはSIP 180リンギングが、アウトバウンドコールのために返されました。エンドポイントは警告されています。
dialing-in: Endpoint is dialing into the conference, not yet in the roster (probably being authenticated).
ダイヤルイン：エンドポイントは、まだ名簿に含まれていない会議にダイヤルしています（おそらく認証されています）。
dialing-out: Focus has dialed out to connect the endpoint to the conference, but the endpoint is not yet in the roster (probably being authenticated).
ダイヤルアウト：フォーカスはダイヤルアウトしてエンドポイントを会議に接続しましたが、エンドポイントはまだ名簿にありません（おそらく認証されています）。
disconnecting: Focus is in the process of disconnecting the endpoint (e.g., in SIP a DISCONNECT or BYE was sent to the endpoint).
切断：焦点はエンドポイントを切断するプロセスにあります（たとえば、SIPでは切断またはバイがエンドポイントに送信されました）。
Note that the defined transient statuses (e.g., disconnecting, alerting, etc.) could generate a lot of traffic. Therefore, implementations MAY choose to generate notifications on these statuses to certain participants only or not generate them at all, subject to local policy.
定義された過渡的なステータス（例：切断、アラートなど）は、多くのトラフィックを生成する可能性があることに注意してください。したがって、実装は、これらのステータスに関する通知を特定の参加者にのみ生成するか、まったく生成しないかを選択する場合があります。
This element contains the method by which the endpoint joined the conference and can assume the following values:
この要素には、エンドポイントが会議に参加した方法が含まれており、次の値を想定できます。
dialed-in: The endpoint dialed into the conference (e.g., in a SIP sent INVITE to the focus), which resulted in successful dialog establishment.
ダイヤルイン：エンドポイントは会議にダイヤルされ（たとえば、SIPが焦点を合わせて送信されたSIP）、ダイアログ確立が成功しました。
dialed-out: The focus has brought the endpoint into the conference (e.g., in SIP, the focus sent a successful INVITE to the endpoint).
ダイヤルアウト：フォーカスによりエンドポイントが会議に参加しました（たとえば、SIPでは、焦点がエンドポイントへの招待状を成功させました）。
focus-owner: The endpoint is the focus for this conference. This status is used only when a participant's UA acts as a conference focus.
フォーカスオーナー：エンドポイントは、この会議の焦点です。このステータスは、参加者のUAが会議の焦点として機能する場合にのみ使用されます。
This element contains information about how the endpoint joined and MAY contain the following sub-elements:
この要素には、エンドポイントがどのように結合されたかに関する情報が含まれており、次のサブエレメントを含む場合があります。
when: This element of the XML dateTime type contains the date and time that the endpoint joined the conference and SHOULD be expressed in Coordinated Universal Time (UTC).
いつ：XML DateTimeタイプのこの要素には、エンドポイントが会議に参加した日時が含まれており、調整されたユニバーサル時間（UTC）で表現する必要があります。
reason: This element contains the reason the endpoint joined the conference. Including the information in the format defined by RFC 3326 [12] is RECOMMENDED. For example,
理由：この要素には、エンドポイントが会議に参加した理由が含まれています。RFC 3326 [12]で定義された形式の情報を含めることをお勧めします。例えば、
<reason>Reason: SIP;text="Ad-hoc Invitation"</reason>
by: This element contains the URI of the entity that caused the endpoint to join the conference.
By：この要素には、エンドポイントが会議に参加する原因となったエンティティのURIが含まれています。
This element contains the method by which the endpoint departed the conference and can assume the following values:
この要素には、エンドポイントが会議を出発する方法が含まれており、次の値を想定できます。
departed: In SIP, the endpoint sent a BYE, thus leaving the conference.
出発：SIPでは、エンドポイントがさようならを送信し、会議を去りました。
booted: In SIP, the endpoint was sent a BYE by the focus, ejecting him/her out of the conference. Alternatively, the endpoint tried to dial into the conference but was rejected by the focus due to local policy.
ブート：SIPでは、エンドポイントは焦点によってさようなら送信され、会議から彼/彼女を追い出しました。あるいは、エンドポイントは会議にダイヤルしようとしましたが、現地の方針により焦点によって拒否されました。
failed: In SIP, the server tried to bring the endpoint into the conference, but its attempt to contact the specific endpoint resulted in a non-200 class final response. Alternatively, the endpoint tried to dial into the conference without success due to technical reasons.
失敗：SIPでは、サーバーはエンドポイントを会議に持ち込もうとしましたが、特定のエンドポイントに接触しようとする試みは、非200クラスの最終応答をもたらしました。あるいは、エンドポイントは、技術的な理由により、成功せずに会議にダイヤルしようとしました。
busy: In SIP, the server tried to bring the endpoint into the conference, but its attempt to contact the specific endpoint resulted in a 486 "Busy Here" final response. Alternatively, the endpoint tried to dial into the conference but the focus responded with 486 response.
ビジー：SIPでは、サーバーはエンドポイントを会議に持ち込もうとしましたが、特定のエンドポイントに接触しようとする試みにより、486の「ここで忙しい」最終応答が得られました。あるいは、エンドポイントは会議にダイヤルしようとしましたが、フォーカスは486の応答で応答しました。
This element contains information about the endpoint's departure from the conference and MAY contain the following sub-elements: when: This element of the XML dateTime type contains the date and time that the endpoint departed the conference and SHOULD be expressed in Coordinated Universal Time (UTC).
この要素には、エンドポイントの会議からの出発に関する情報が含まれており、次のサブ要素が含まれる場合があります。いつ：XML DateTimeタイプのこの要素には、エンドポイントが会議を出発し、調整されたユニバーサル時間で表現する必要があります（UTC））。
reason: This element contains the reason the endpoint departed the conference. When known and meaningful, including the information as conveyed/reported by the call signaling in the format defined by RFC 3326 [12] is RECOMMENDED. For example,
理由：この要素には、エンドポイントが会議を去った理由が含まれています。RFC 3326 [12]で定義された形式でのコールシグナル伝達によって伝えられた/報告された情報を含む、既知で意味のある場合、推奨されます。例えば、
<reason>Reason: SIP;cause=415;text="Unsupported Media Type"</reason>
by: This element contains the URI of the entity that caused the endpoint to depart the conference.
By：この要素には、エンドポイントが会議を出発したエンティティのURIが含まれています。
This element contains information about a single media stream and is included for each media stream being established between the focus and the <endpoint>. The media stream definition can be found in SDP [3].
この要素には、単一のメディアストリームに関する情報が含まれており、フォーカスと<EndPoint>の間に確立されている各メディアストリームに含まれています。メディアストリームの定義は、SDPに記載されています[3]。
Note that if the <call-info> sub-element of the endpoint is not included in the document by the server, it is possible that the media streams listed under the common <endpoint> were established by separate signaling sessions.
エンドポイントの<call-info>サブエレメントがサーバーによってドキュメントに含まれていない場合、共通<endpoint>にリストされているメディアストリームが個別のシグナリングセッションによって確立された可能性があることに注意してください。
The <call-info> element provides detailed call signaling information for a call being maintained between the participant and the focus. Privacy policies MUST be consulted before revealing this information to other participants.
<call-info>要素は、参加者とフォーカスの間で維持されているコールの詳細なコールシグナル情報を提供します。この情報を他の参加者に公開する前に、プライバシーポリシーに相談する必要があります。
The <sip> sub-element contains the SIP dialog identifier of the endpoint's dialog with the focus. The element includes sub-elements <display-text>, <call-id>, <to-tag>, <from-tag>.
<sip>サブエレメントには、焦点を備えたエンドポイントのダイアログのSIPダイアログ識別子が含まれています。要素には、sub-elements <display-text>、<call-id>、<to-tag>、<from-tag>が含まれます。
In future, the <call-info> element can be expanded to include call signaling protocol information for other protocols besides SIP.
将来、<Call-Info>要素を拡張して、SIP以外の他のプロトコルのコールシグナル伝達プロトコル情報を含めることができます。
This section describes the <media> element in more detail.
このセクションでは、<media>要素について詳しく説明します。
A single 'id' attribute is defined for this element. This is the media stream identifier being generated by the server such that its value is unique in the endpoint context. This attribute is the key to refer to a particular media stream in the conference document.
この要素に対して単一の「ID」属性が定義されています。これは、サーバーによって生成されるメディアストリーム識別子であり、その値がエンドポイントのコンテキストで一意になるようにします。この属性は、会議文書の特定のメディアストリームを参照するための鍵です。
The following child elements are defined for <media>:
次の子要素は<media>用に定義されています。
This element contains the display text for the media stream. The value of this element corresponds to the SDP description media attribute ("i") defined in SDP [3].
この要素には、メディアストリームの表示テキストが含まれています。この要素の値は、SDP [3]で定義されているSDP説明メディア属性（ "i"）に対応します。
This element contains the media type for the media stream. The value of this element MUST be one of the values registered for "media" of SDP [3] and its later revision(s).
この要素には、メディアストリームのメディアタイプが含まれています。この要素の値は、SDP [3]の「メディア」に登録されている値の1つでなければなりません。
The <label> element carries a unique identifier for this stream among all streams in the conference and is assigned by the focus. The value of this element will typically correspond to the SDP "label" media attribute defined in [17] and is exchanged between a participant and a focus over the signaling connection between them.
<label>要素は、会議のすべてのストリームの中でこのストリームの一意の識別子を持ち、フォーカスによって割り当てられます。この要素の値は通常、[17]で定義されているSDP「ラベル」メディア属性に対応し、参加者とそれらの間のシグナリング接続に焦点を合わせて交換されます。
If the <available-media> information (described in Section 5.3.4) is included in the conference document, the value of this element MUST be equal to the 'label' value of the corresponding media stream <entry> in the <available-media> container.
<利用可能なメディア>情報（セクション5.3.4で説明）が会議文書に含まれている場合、この要素の値は、対応するメディアストリームの「ラベル」値に等しくなければなりません。メディア>コンテナ。
The <src-id> element, if applicable, carries the information about the actual source of the media. For example, for Real-time Transport Protocol (RTP) / RTP Control Protocol (RTCP) [13] media streams, the value MUST contain the synchronization source (SSRC) identifier value generated by the endpoint for the stream it sends.
<src-id>要素は、該当する場合、メディアの実際のソースに関する情報を伝えます。たとえば、リアルタイムトランスポートプロトコル（RTP） / RTP制御プロトコル（RTCP）[13]メディアストリームの場合、値には、送信されるストリームのエンドポイントによって生成された同期ソース（SSRC）識別子値を含める必要があります。
When an RTP mixer generates a contributing source (CSRC) identifiers' list according to RTP/RTCP [13], it inserts a list of the SSRC identifiers of the sources that contributed to the generation of a particular packet into the RTP header of that packet. A quote from RFC 3550 [13] explains as follows: "An example application is audio conferencing where a mixer indicates all the talkers whose speech was combined to produce the outgoing packet, allowing the receiver to indicate the current talker, even though all the audio packets contain the same SSRC identifier (that of the mixer)." If an RTP mixer compliant to the above is used, participants can perform an SSRC to user mapping and identify "a current speaker".
RTPミキサーがRTP/RTCP [13]に従って寄与源（CSRC）識別子のリストを生成すると、特定のパケットの生成に貢献したソースのSSRC識別子のリストをそのパケットのRTPヘッダーに挿入します。。RFC 3550 [13]からの引用は次のように説明しています。「例のアプリケーションは、ミキサーが発信パケットを生成するためにスピーチを組み合わせたすべての話者を示すオーディオ会議です。パケットには、同じSSRC識別子（ミキサーの識別子）が含まれています。」上記に準拠したRTPミキサーを使用すると、参加者はSSRCを実行してユーザーマッピングを実行して「現在のスピーカー」を特定できます。
The element <status> indicates the status in both directions of the media stream and has the values "sendrecv", "sendonly", "recvonly", or "inactive" as defined in SDP [3] and its later revision(s). Note that value specifies the direction from the participant's point of view. For example, a muted participant's stream will have the value of "recvonly".
要素<status>は、メディアストリームの両方向のステータスを示し、SDP [3]およびその後の改訂で定義されているように、「sendrecv」、「sendonly」、「recvonly」、または "inactive」値を持っています。値は、参加者の観点から方向を指定することに注意してください。たとえば、ミュートされた参加者のストリームには、「recvonly」の価値があります。
If a participant in the main conference joins a sidebar, a new <user> element representing the user is created either as a part of a separate sub-conference referenced from the <sidebars-by-ref> element or under one of the <sidebars-by-val> elements as described below.
メインカンファレンスの参加者がサイドバーに参加する場合、ユーザーを表す新しい<ユーザー>要素が<サイドバーごとに参照される別のサブカンファレンスの一部として作成されます。-val-val>以下で説明する要素。
Note that the <user> in the main roster is not being deleted, but its media statuses can be updated to reflect the effect being caused by his/her participation in the sidebar. The display of this information can vary among subscribers to the same conference information, subject to local policies and to the subscriber role both in the sidebar and in the main conference.
メイン名簿の<ユーザー>は削除されていませんが、メディアステータスを更新して、サイドバーへの参加によって引き起こされる効果を反映することができます。この情報の表示は、地域のポリシーとサイドバーとメイン会議の両方での加入者の役割を条件として、同じ会議情報のサブスクライバー間で異なる場合があります。
This element contains a set of <entry> child elements, each containing a sidebar conference URI. The recipient of the information can then subscribe to sidebar information independently from the main conference package subscription.
この要素には、それぞれがサイドバーカンファレンスURIを含む<エントリ>子要素のセットが含まれています。情報の受信者は、メインカンファレンスパッケージサブスクリプションから独立してサイドバー情報を購読できます。
This element contains a set of <entry> child elements, each containing information about a single sidebar. By using this element of conference-type, the server can include a full or partial description of each sidebar (as a sub-conference) in the body of the main conference document.
この要素には、それぞれが単一のサイドバーに関する情報を含む<エントリ>子要素のセットが含まれています。会議タイプのこの要素を使用することにより、サーバーは、メインカンファレンスドキュメントの本文に、各サイドバー（サブカンファレンスとして）の完全または部分的な説明を含めることができます。
<?xml version="1.0" encoding="UTF-8" ?>
<xs:schema
targetNamespace="urn:ietf:params:xml:ns:conference-info"
xmlns:tns="urn:ietf:params:xml:ns:conference-info"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns="urn:ietf:params:xml:ns:conference-info"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<!--
This imports the xml:language definition
-->
<xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/03/xml.xsd"/>
<!--
CONFERENCE ELEMENT
-->
<xs:element name="conference-info" type="conference-type"/>
<!--
CONFERENCE TYPE
-->
<xs:complexType name="conference-type">
<xs:sequence>
<xs:element name="conference-description"
type="conference-description-type" minOccurs="0"/>
<xs:element name="host-info"
type="host-type" minOccurs="0"/>
<xs:element name="conference-state"
type="conference-state-type" minOccurs="0"/>
<xs:element name="users"
type="users-type" minOccurs="0"/>
<xs:element name="sidebars-by-ref"
type="uris-type" minOccurs="0"/>
<xs:element name="sidebars-by-val"
type="sidebars-by-val-type" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="entity"
type="xs:anyURI" use="required"/>
<xs:attribute name="state"
type="state-type" use="optional" default="full"/>
<xs:attribute name="version"
type="xs:unsignedInt" use="optional"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<!--
STATE TYPE
-->
<xs:simpleType name="state-type">
<xs:restriction base="xs:string">
<xs:enumeration value="full"/>
<xs:enumeration value="partial"/>
<xs:enumeration value="deleted"/>
</xs:restriction>
</xs:simpleType>
<!--
CONFERENCE DESCRIPTION TYPE
-->
<xs:complexType name="conference-description-type">
<xs:sequence>
<xs:element name="display-text"
type="xs:string" minOccurs="0"/>
<xs:element name="subject"
type="xs:string" minOccurs="0"/>
<xs:element name="free-text"
type="xs:string" minOccurs="0"/>
<xs:element name="keywords"
type="keywords-type" minOccurs="0"/>
<xs:element name="conf-uris"
type="uris-type" minOccurs="0"/>
<xs:element name="service-uris"
type="uris-type" minOccurs="0"/>
<xs:element name="maximum-user-count"
type="xs:unsignedInt" minOccurs="0"/>
<xs:element name="available-media"
type="conference-media-type" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<!--
HOST TYPE
-->
<xs:complexType name="host-type">
<xs:sequence>
<xs:element name="display-text" type="xs:string"
minOccurs="0"/>
<xs:element name="web-page" type="xs:anyURI"
minOccurs="0"/>
<xs:element name="uris" type="uris-type"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<!--
CONFERENCE STATE TYPE
-->
<xs:complexType name="conference-state-type">
<xs:sequence>
<xs:element name="user-count" type="xs:unsignedInt"
minOccurs="0"/>
<xs:element name="active" type="xs:boolean"
minOccurs="0"/>
<xs:element name="locked" type="xs:boolean"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<!--
CONFERENCE MEDIA TYPE
-->
<xs:complexType name="conference-media-type">
<xs:sequence>
<xs:element name="entry" type="conference-medium-type"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<!--
CONFERENCE MEDIUM TYPE
-->
<xs:complexType name="conference-medium-type">
<xs:sequence>
<xs:element name="display-text" type="xs:string"
minOccurs="0"/>
<xs:element name="type" type="xs:string"/>
<xs:element name="status" type="media-status-type"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="label" type="xs:string"
use="required"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<!--
URIs TYPE
-->
<xs:complexType name="uris-type">
<xs:sequence>
<xs:element name="entry" type="uri-type"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="state" type="state-type"
use="optional" default="full"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<!--
URI TYPE
-->
<xs:complexType name="uri-type">
<xs:sequence>
<xs:element name="uri" type="xs:anyURI"/>
<xs:element name="display-text" type="xs:string"
minOccurs="0"/>
<xs:element name="purpose" type="xs:string"
minOccurs="0"/>
<xs:element name="modified" type="execution-type"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<!--
KEYWORDS TYPE
-->
<xs:simpleType name="keywords-type">
<xs:list itemType="xs:string"/>
</xs:simpleType>
<!--
USERS TYPE
-->
<xs:complexType name="users-type">
<xs:sequence>
<xs:element name="user" type="user-type"
minOccurs="0" maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="state" type="state-type"
use="optional" default="full"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<!--
USER TYPE
-->
<xs:complexType name="user-type">
<xs:sequence>
<xs:element name="display-text" type="xs:string"
minOccurs="0"/>
<xs:element name="associated-aors" type="uris-type"
minOccurs="0"/>
<xs:element name="roles" type="user-roles-type"
minOccurs="0"/>
<xs:element name="languages" type="user-languages-type"
minOccurs="0"/>
<xs:element name="cascaded-focus" type="xs:anyURI"
minOccurs="0"/>
<xs:element name="endpoint" type="endpoint-type"
minOccurs="0" maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="entity" type="xs:anyURI"/>
<xs:attribute name="state" type="state-type"
use="optional" default="full"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<!--
USER ROLES TYPE
-->
<xs:complexType name="user-roles-type">
<xs:sequence>
<xs:element name="entry" type="xs:string"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<!--
USER LANGUAGES TYPE
-->
<xs:simpleType name="user-languages-type">
<xs:list itemType="xs:language"/>
</xs:simpleType>
<!--
ENDPOINT TYPE
-->
<xs:complexType name="endpoint-type">
<xs:sequence>
<xs:element name="display-text" type="xs:string"
minOccurs="0"/>
<xs:element name="referred" type="execution-type"
minOccurs="0"/>
<xs:element name="status" type="endpoint-status-type"
minOccurs="0"/>
<xs:element name="joining-method" type="joining-type"
minOccurs="0"/>
<xs:element name="joining-info"
type="execution-type"
minOccurs="0"/>
<xs:element name="disconnection-method"
type="disconnection-type"
minOccurs="0"/>
<xs:element name="disconnection-info"
type="execution-type"
minOccurs="0"/>
<xs:element name="media" type="media-type"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="call-info" type="call-type"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="entity" type="xs:string"/>
<xs:attribute name="state" type="state-type"
use="optional" default="full"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<!--
ENDPOINT STATUS TYPE
-->
<xs:simpleType name="endpoint-status-type">
<xs:restriction base="xs:string">
<xs:enumeration value="pending"/>
<xs:enumeration value="dialing-out"/>
<xs:enumeration value="dialing-in"/>
<xs:enumeration value="alerting"/>
<xs:enumeration value="on-hold"/>
<xs:enumeration value="connected"/>
<xs:enumeration value="muted-via-focus"/>
<xs:enumeration value="disconnecting"/>
<xs:enumeration value="disconnected"/>
</xs:restriction>
</xs:simpleType>
<!--
JOINING TYPE
-->
<xs:simpleType name="joining-type">
<xs:restriction base="xs:string">
<xs:enumeration value="dialed-in"/>
<xs:enumeration value="dialed-out"/>
<xs:enumeration value="focus-owner"/>
</xs:restriction>
</xs:simpleType>
<!--
DISCONNECTION TYPE
-->
<xs:simpleType name="disconnection-type">
<xs:restriction base="xs:string">
<xs:enumeration value="departed"/>
<xs:enumeration value="booted"/>
<xs:enumeration value="failed"/>
<xs:enumeration value="busy"/>
</xs:restriction>
</xs:simpleType>
<!--
EXECUTION TYPE
-->
<xs:complexType name="execution-type">
<xs:sequence>
<xs:element name="when" type="xs:dateTime"
minOccurs="0"/>
<xs:element name="reason" type="xs:string"
minOccurs="0"/>
<xs:element name="by" type="xs:anyURI"
minOccurs="0"/>
</xs:sequence>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<!--
CALL TYPE
-->
<xs:complexType name="call-type">
<xs:choice>
<xs:element name="sip" type="sip-dialog-id-type"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:choice>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<!--
SIP DIALOG ID TYPE
-->
<xs:complexType name="sip-dialog-id-type">
<xs:sequence>
<xs:element name="display-text" type="xs:string"
minOccurs="0"/>
<xs:element name="call-id" type="xs:string"/>
<xs:element name="from-tag" type="xs:string"/>
<xs:element name="to-tag" type="xs:string"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<!--
MEDIA TYPE
-->
<xs:complexType name="media-type">
<xs:sequence>
<xs:element name="display-text" type="xs:string"
minOccurs="0"/>
<xs:element name="type" type="xs:string"
minOccurs="0"/>
<xs:element name="label" type="xs:string"
minOccurs="0"/>
<xs:element name="src-id" type="xs:string"
minOccurs="0"/>
<xs:element name="status" type="media-status-type"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="id" type="xs:string"
use="required"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<!--
MEDIA STATUS TYPE
-->
<xs:simpleType name="media-status-type">
<xs:restriction base="xs:string">
<xs:enumeration value="recvonly"/>
<xs:enumeration value="sendonly"/>
<xs:enumeration value="sendrecv"/>
<xs:enumeration value="inactive"/>
</xs:restriction>
</xs:simpleType>
<!--
SIDEBARS BY VAL TYPE
-->
<xs:complexType name="sidebars-by-val-type">
<xs:sequence>
<xs:element name="entry" type="conference-type"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="state" type="state-type"
use="optional" default="full"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
</xs:schema>
The following is an example of a full conference information document:
以下は、完全な会議情報文書の例です。
<?xml version="1.0" encoding="UTF-8"?>
<conference-info
xmlns="urn:ietf:params:xml:ns:conference-info"
entity="sips:conf233@example.com"
state="full" version="1">
<!--
CONFERENCE INFO
-->
<conference-description>
<subject>Agenda: This month's goals</subject>
<service-uris>
<entry>
<uri>http://sharepoint/salesgroup/</uri>
<purpose>web-page</purpose>
</entry>
</service-uris>
</conference-description>
<!--
CONFERENCE STATE
-->
<conference-state>
<user-count>33</user-count>
</conference-state>
<!--
USERS
-->
<users>
<user entity="sip:bob@example.com" state="full">
<display-text>Bob Hoskins</display-text>
<!--
ENDPOINTS
-->
<endpoint entity="sip:bob@pc33.example.com">
<display-text>Bob's Laptop</display-text>
<status>disconnected</status>
<disconnection-method>departed</disconnection-method>
<disconnection-info>
<when>2005-03-04T20:00:00Z</when>
<reason>bad voice quality</reason>
<by>sip:mike@example.com</by>
</disconnection-info>
<!--
MEDIA
-->
<media id="1">
<display-text>main audio</display-text>
<type>audio</type>
<label>34567</label>
<src-id>432424</src-id>
<status>sendrecv</status>
</media>
</endpoint>
</user>
<!--
USER
-->
<user entity="sip:alice@example.com" state="full">
<display-text>Alice</display-text>
<!--
ENDPOINTS
-->
<endpoint entity="sip:4kfk4j392jsu@example.com;grid=433kj4j3u">
<status>connected</status>
<joining-method>dialed-out</joining-method>
<joining-info>
<when>2005-03-04T20:00:00Z</when>
<by>sip:mike@example.com</by>
</joining-info>
<!--
MEDIA
-->
<media id="1">
<display-text>main audio</display-text>
<type>audio</type>
<label>34567</label>
<src-id>534232</src-id>
<status>sendrecv</status>
</media>
</endpoint>
</user>
</users>
</conference-info>
The following is an example of a partial conference information document. In this example, there are 32 participants in a voice conference. The user Bob has been ejected from the conference by Mike due to bad voice quality. Note that there are three sidebars in the conference; two are referenced just by their sidebar URIs, and information about the third sidebar is included in this notification. Also note that while this conference offers both audio and video capabilities, only audio is currently in use.
以下は、部分的な会議情報文書の例です。この例では、音声会議には32人の参加者がいます。ユーザーボブは、音声の質が悪いため、マイクによる会議から追い出されました。会議には3つのサイドバーがあることに注意してください。2つはサイドバーウリスのみで参照されており、サードサイドバーに関する情報はこの通知に含まれています。また、この会議はオーディオ機能とビデオ機能の両方を提供していますが、現在使用中です。
<?xml version="1.0" encoding="UTF-8"?>
<conference-info
xmlns="urn:ietf:params:xml:ns:conference-info"
entity="sips:conf233@example.com"
state="partial" version="5">
<!--
CONFERENCE INFO
-->
<conference-description>
<display-text>Weekly Sales Meeting</display-text>
<subject>Agenda: This month's goals</subject>
<free-text>We will start strict on time</free-text>
<keywords>sales meeting weekly</keywords>
<conf-uris>
<entry>
<uri>tel:+18005671234</uri>
<display-text>TTI Bridge</display-text>
<purpose>participation</purpose>
</entry>
<entry>
<uri>h323:conf545@h323.example.com</uri>
<purpose>participation</purpose>
</entry>
<entry>
<uri>http://real.streaming.com/54634/live.ram</uri>
<purpose>streaming</purpose>
</entry>
</conf-uris>
<service-uris>
<entry>
<uri>http://sharepoint/salesgroup/</uri>
<purpose>web-page</purpose>
</entry>
<entry>
<uri>http://quicktime.com/54634/recording.mov</uri>
<display-text>Quicktime</display-text>
<purpose>recording</purpose>
</entry>
</service-uris>
<maximum-user-count>100</maximum-user-count>
<available-media>
<entry label="34567">
<display-text>main audio</display-text>
<type>audio</type>
<status>sendrecv</status>
</entry>
<entry label="34569">
<display-text>main video</display-text>
<type>video</type>
<status>inactive</status>
</entry>
</available-media>
</conference-description>
<!--
HOST INFO
-->
<host-info>
<display-text>Sales Host</display-text>
<web-page>http://sharepoint/salesgroup/hosts/</web-page>
<uris>
<entry>
<uri>sip:sales@example.com</uri>
</entry>
</uris>
</host-info>
<!--
CONFERENCE STATE
-->
<conference-state>
<user-count>32</user-count>
<active>true</active>
<locked>false</locked>
</conference-state>
<!--
USERS
-->
<users>
<user entity="sip:bob@example.com">
<display-text>Bob Hoskins</display-text>
<associated-aors>
<entry>
<uri>mailto:bob@example.com</uri>
<display-text>email</display-text>
</entry>
</associated-aors>
<roles>
<entry>participant</entry>
</roles>
<languages>en</languages>
<!--
ENDPOINTS
-->
<endpoint entity="sip:bob@pc33.example.com">
<display-text>Bob's Laptop</display-text>
<referred>
<when>2005-03-04T20:00:00Z</when>
<reason>expert required</reason>
<by>sip:mike@example.com</by>
</referred>
<status>disconnecting</status>
<joining-method>dialed-out</joining-method>
<joining-info>
<when>2005-03-04T20:00:00Z</when>
<reason>invitation</reason>
<by>sip:mike@example.com</by>
</joining-info>
<disconnection-method>booted</disconnection-method>
<disconnection-info>
<when>2005-03-04T20:00:00Z</when>
<reason>bad voice quality</reason>
<by>sip:mike@example.com</by>
</disconnection-info>
<!--
MEDIA
-->
<media id="1">
<display-text>main audio</display-text>
<type>audio</type>
<label>34567</label>
<src-id>432424</src-id>
<status>sendrecv</status>
</media>
<!--
CALL INFO
-->
<call-info>
<sip>
<display-text>full info</display-text>
<call-id>hsjh8980vhsb78</call-id>
<from-tag>vav738dvbs</from-tag>
<to-tag>8954jgjg8432</to-tag>
</sip>
</call-info>
</endpoint>
</user>
</users>
<!--
SIDEBARS BY REFERENCE
-->
<sidebars-by-ref state="partial">
<entry>
<uri>sips:conf233@example.com;grid=45</uri>
<display-text>sidebar with Carol</display-text>
</entry>
<entry>
<uri>sips:conf233@example.com;grid=21</uri>
<display-text>private with Peter</display-text>
</entry>
</sidebars-by-ref>
<!--
SIDEBARS BY VALUE
-->
<sidebars-by-val state="partial">
<entry entity="sips:conf233@example.com;grid=77"
state="partial">
<users>
<user entity="sip:bob@example.com"/>
<user entity="sip:mark@example.com"/>
<user entity="sip:dan@example.com"/>
</users>
</entry>
</sidebars-by-val>
</conference-info>
Subscriptions to conference state information can reveal very sensitive information. For this reason, it is RECOMMENDED that a focus use a strong means for authentication and conference information protection and that it apply comprehensive authorization rules when using the conference notification mechanism defined in this document. The following sections will discuss each of these aspects in more detail.
会議の状態情報へのサブスクリプションは、非常に機密情報を明らかにすることができます。このため、フォーカスは、認証と会議の情報保護に強力な手段を使用し、このドキュメントで定義されている会議通知メカニズムを使用する際に包括的な認可規則を適用することをお勧めします。次のセクションでは、これらの各側面についてさらに詳しく説明します。
It is RECOMMENDED that a focus authenticate a conference package subscriber using the normal SIP authentication mechanisms, such as Digest as defined in Section 22 of RFC 3261 [8].
フォーカスは、RFC 3261のセクション22で定義されているダイジェストなどの通常のSIP認証メカニズムを使用して、会議パッケージサブスクライバーを認証することをお勧めします[8]。
The mechanism used for conveying the conference information MUST ensure integrity and SHOULD ensure confidentially of the information. In order to achieve these, an end-to-end SIP encryption mechanism, such as S/MIME described in Section 26.2.4 of RFC 3261 [8], SHOULD be used.
会議情報を伝えるために使用されるメカニズムは、整合性を確保し、情報の機密を確保する必要があります。これらを達成するには、RFC 3261 [8]のセクション26.2.4で説明されているS/MIMEなどのエンドツーエンドSIP暗号化メカニズムを使用する必要があります。
If a strong end-to-end security means (such as above) is not available, it is RECOMMENDED that a focus use mutual hop-by-hop Transport Layer Security (TLS) authentication and encryption mechanisms described in Section 26.2.2 "SIPS URI Scheme" and Section 26.3.2.2 "Interdomain Requests" of RFC 3261 [8].
強力なエンドツーエンドのセキュリティ手段（上記など）が利用できない場合は、セクション26.2.2 "SIPSで説明されている相互ホップバイホップトランスポートレイヤーセキュリティ（TLS）認証と暗号化メカニズムを使用することをお勧めします。RFC 3261 [8]のURIスキーム "およびセクション26.3.2.2「ドメイン間要求」。
Generally speaking, conference applications are very concerned about authorization decisions. Mechanisms for establishing and enforcing such authorization rules are a central concept throughout the SIP Conferencing Framework [16]. Because most of the information about a conference can be presented using the conference package, many of the authorization rules directly apply to this specification. As a result, a notification server MUST be capable of generating distinct conference information views to different subscribers, subject to a subscriber's role in a conference, personal access rights, etc. - all subject to local authorization policies and rules.
一般的に言えば、会議の申請書は、許可の決定に非常に懸念しています。このような承認ルールを確立および実施するためのメカニズムは、SIP会議のフレームワーク全体を通して中心的な概念です[16]。会議に関する情報のほとんどは会議パッケージを使用して提示できるため、承認ルールの多くはこの仕様に直接適用されます。その結果、通知サーバーは、異なるサブスクライバーに異なる会議情報ビューを生成できる必要があります。これは、会議におけるサブスクライバーの役割、個人アクセス権などを条件としています。
Since a focus provides participant identity information using this event package, participant privacy needs to be taken into account. A focus MUST support requests by participants for privacy. Privacy can be indicated by the conference policy - for every participant or select participants. It can also be indicated in the session signaling. In SIP, this can be done using the Privacy header field described in RFC 3323 [11]. For a participant requesting privacy, no identity information SHOULD be revealed by the focus in any included URI (e.g., the Address of Record, Contact, or GRUU). For these cases, the anonymous URI generation method outlined in Section 5.6 of this document MUST be followed.
フォーカスはこのイベントパッケージを使用して参加者のアイデンティティ情報を提供するため、参加者のプライバシーを考慮する必要があります。フォーカスは、プライバシーについて参加者からのリクエストをサポートする必要があります。プライバシーは、すべての参加者または選択した参加者について、会議ポリシーで示すことができます。セッションシグナリングでも示される可能性があります。SIPでは、これはRFC 3323 [11]で説明されているプライバシーヘッダーフィールドを使用して実行できます。プライバシーを要求する参加者の場合、含まれているURI（例：記録、連絡先、またはGruuのアドレス）の焦点によって身元情報を明らかにする必要はありません。これらのケースでは、このドキュメントのセクション5.6で概説されている匿名のURI生成法に従う必要があります。
This document registers a SIP event package, a new MIME type, application/conference-info+xml, a new XML namespace, and a new XML schema, and creates a sub-registry "URI purposes" under the existing registry: http://www.iana.org/assignments/sip-parameters.
このドキュメントは、SIPイベントパッケージ、新しいMIMEタイプ、アプリケーション/Conference-INFO XML、新しいXMLネームスペース、新しいXMLスキーマを登録し、既存のレジストリの下に「URIの目的」を作成します：http：//www.iana.org/assignments/sip-parameters。
This specification registers an event package, based on the registration procedures defined in RFC 3265 [10]. The following is the information required for such a registration: Package Name: conference
この仕様は、RFC 3265 [10]で定義されている登録手順に基づいて、イベントパッケージを登録します。以下は、そのような登録に必要な情報です：パッケージ名：会議
Package or Template-Package: This is a package.
パッケージまたはテンプレートパッケージ：これはパッケージです。
Published Document: RFC 4575
公開ドキュメント：RFC 4575
Person to Contact: IETF SIPPING Working Group <sipping@ietf.org>, as
designated by the IESG <iesg@ietf.org>
MIME media type name: application
MIMEメディアタイプ名：アプリケーション
MIME subtype name: conference-info+xml
MIMEサブタイプ名：Conference-INFO XML
Mandatory parameters: none
必須パラメーター：なし
Optional parameters: Same as charset parameter application/xml as specified in RFC 3023 [7]
オプションのパラメーター：RFC 3023で指定されているCharsetパラメーターアプリケーション/XMLと同じ[7]
Encoding considerations: Same as encoding considerations of application/xml as specified in RFC 3023 [7]
考慮事項のエンコード：RFC 3023で指定されているアプリケーション/XMLの考慮事項のエンコードと同じ[7]
Security considerations: See Section 10 of RFC 3023 [7] and Section 8 of this specification
セキュリティ上の考慮事項：RFC 3023 [7]のセクション10およびこの仕様のセクション8を参照してください
Interoperability considerations: none
相互運用性の考慮事項：なし
Published specification: This document
公開された仕様：このドキュメント
Applications which use this media type: This document type has been used to support SIP conferencing applications
このメディアタイプを使用するアプリケーション：このドキュメントタイプは、SIP会議アプリケーションをサポートするために使用されています
Additional Information:
追加情報：
Magic Number: None
マジックナンバー：なし
File Extension: .xml
ファイル拡張子：.xml
Macintosh file type code: "TEXT"
Macintoshファイルタイプコード：「テキスト」
Personal and email address for further information: IETF SIPPING
Working Group <sipping@ietf.org>, as designated by the IESG
<iesg@ietf.org>
Intended usage: COMMON
Author/Change controller: IETF SIPPING Working Group
<sipping@ietf.org>, as designated by the IESG <iesg@ietf.org>
This section registers a new XML namespace, as per the guidelines in RFC 3688 [21].
このセクションでは、RFC 3688のガイドラインに従って、新しいXMLネームスペースを登録します[21]。
URI: The URI for this namespace is
urn:ietf:params:xml:ns:conference-info
Registrant Contact: IETF SIPPING Working Group <sipping@ietf.org>,
as designated by the IESG <iesg@ietf.org>
XML:
XML：
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>Conference Information Namespace</title>
</head
<body>
<h1>Namespace for Conference Information</h1>
<h2>urn:ietf:params:xml:ns:conference-info</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc4575.txt">
RFC4575</a>.</p>
</body>
</html>
END
This specification registers a schema, as per the guidelines in RFC 3688 [21].
この仕様は、RFC 3688のガイドラインに従って、スキーマを登録します[21]。
URI: please assign
URI：割り当ててください
Registrant Contact: IETF SIPPING Working Group <sipping@ietf.org>,
as designated by the IESG <iesg@ietf.org>
XML: The XML can be found as the sole content of Section 6.
XML：XMLは、セクション6の唯一の内容として見つけることができます。
The IANA has created a new sub-registry, "URI purposes", under the already existing registry: http://www.iana.org/assignments/sip-parameters.
IANAは、既存のレジストリ：http：//www.iana.org/assignments/sip-parametersの下で、新しいサブレジストリ「URIの目的」を作成しました。
The purpose of a URI is an XML element, encoded in the conference event package RFC 4575. The value of the <purpose> element indicates the intended usage of the URI in the context of the conference event package and is defined in Sections 5.3.1 and 5.3.2 of this specification.
URIの目的は、会議イベントパッケージRFC 4575にエンコードされたXML要素です。<目的>要素の値は、会議イベントパッケージのコンテキストでURIの意図した使用法を示し、セクション5.3.1で定義されています。この仕様の5.3.2。
This sub-registry is defined as a table that contains the following three columns:
このサブレジストリは、次の3つの列を含むテーブルとして定義されています。
Value: The token under registration
値：登録中のトークン
Description: A descriptive text defining the intended usage of the URI
説明：URIの意図された使用法を定義する記述テキスト
Document: A reference to the document defining the registration
ドキュメント：登録を定義するドキュメントへの参照
The IANA has created the table with the initial content as defined below:
IANAは、以下に定義されている最初のコンテンツを使用してテーブルを作成しました。
Value Description Document
------- ---------------------------------- ----------
participation The URI can be used to join the [RFC 4575] conference
参加URIは[RFC 4575]会議に参加するために使用できます
streaming The URI can be used to access the [RFC 4575] streamed conference data
URIのストリーミングを使用して、[RFC 4575]ストリーミングされた会議データにアクセスできます
event The URI can be used to subscribe [RFC 4575] to the conference event package
イベントURIを使用して、会議イベントパッケージに[RFC 4575]を購読することができます
recording The URI can be used to access the [RFC 4575] recorded conference data
URIの記録を使用して、[RFC 4575]記録された会議データにアクセスできます
web-page The URI can be used to access a [RFC 4575] web page that contains additional information of the conference
WebページURIを使用して、会議の追加情報を含む[RFC 4575] Webページにアクセスできます
New values of the "URI purposes" are registered by the IANA and are specification required according to the definition of RFC 2434 [4]. The IANA Considerations section of the specification MUST include the following information: Value: The value of the <purpose> element to be registered
「URI目的」の新しい値はIANAによって登録されており、RFC 2434の定義に従って必要な仕様です[4]。仕様のIANA考慮事項セクションには、次の情報を含める必要があります。値：登録する<目的>要素の値
Description: A short description of the intended usage of the URI
説明：URIの意図された使用法の簡単な説明
The authors would like to thank Dan Petrie, Sean Olson, Alan Johnston, Rohan Mahy, Cullen Jennings, Brian Rosen, Roni Even, and Miguel Garcia for their comments and inputs.
著者は、ダン・ペトリー、ショーン・オルソン、アラン・ジョンストン、ロハン・マヒー、カレン・ジェニングス、ブライアン・ローゼン、ロニ・偶数、ミゲル・ガルシアのコメントとインプットに感謝したいと思います。
[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] Moats, R., "URN Syntax", RFC 2141, May 1997.
[2] Moats、R。、「urn構文」、RFC 2141、1997年5月。
[3] Handley, M., Jacobson, V. and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[3] Handley、M.、Jacobson、V。and C. Perkins、「SDP：セッション説明プロトコル」、RFC 4566、2006年7月。
[4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[4] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 2434、1998年10月。
[5] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS Names", BCP 32, RFC 2606, June 1999.
[5] Eastlake 3rd、D。およびA. Panitz、「予約済みのトップレベルDNS名」、BCP 32、RFC 2606、1999年6月。
[6] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, August 1999.
[6] Moats、R。、「IETFドキュメント用のurnネームスペース」、RFC 2648、1999年8月。
[7] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[7] Murata、M.、St。Laurent、S。、およびD. Kohn、「XML Media Types」、RFC 3023、2001年1月。
[8] 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.
[8] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、 "SIP：SESSION INTIATION Protocol"、RFC 3261、2002年6月。
[9] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[9] Rosenberg、J。およびH. Schulzrinne、「セッション説明プロトコル（SDP）を備えたオファー/回答モデル」、RFC 3264、2002年6月。
[10] Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[10] Roach、A.B。、「セッション開始プロトコル（SIP）特異的イベント通知」、RFC 3265、2002年6月。
[11] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002.
[11] ピーターソン、J。、「セッション開始プロトコル（SIP）のプライバシーメカニズム」、RFC 3323、2002年11月。
[12] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason Header Field for the Session Initiation Protocol (SIP)", RFC 3326, December 2002.
[12] Schulzrinne、H.、Oran、D。、およびG. Camarillo、「セッション開始プロトコル（SIP）のヘッダーフィールドの理由」、RFC 3326、2002年12月。
[13] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[13] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：リアルタイムアプリケーション用の輸送プロトコル」、STD 64、RFC 3550、2003年7月。
[14] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[14] Yergeau、F。、「UTF-8、ISO 10646の変換形式」、STD 63、RFC 3629、2003年11月。
[15] Sparks, R., "The Session Initiation Protocol (SIP) Referred-By Mechanism", RFC 3892, September 2004.
[15] Sparks、R。、「セッション開始プロトコル（SIP）がメカニズムを参照」、RFC 3892、2004年9月。
[16] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol (SIP)", RFC 4353, February 2006.
[16] Rosenberg、J。、「セッション開始プロトコル（SIP）との会議のフレームワーク」、RFC 4353、2006年2月。
[17] Levin, O. and G. Camarillo, "The Session Description Protocol (SDP) Label Attribute", RFC 4574, August 2006.
[17] Levin、O。およびG. Camarillo、「セッション説明プロトコル（SDP）ラベル属性」、RFC 4574、2006年8月。
[18] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[18] Schulzrinne、H.、Rao、A。、およびR. Lanphier、「リアルタイムストリーミングプロトコル（RTSP）」、RFC 2326、1998年4月。
[19] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004.
[19] Schulzrinne、H。、「電話番号のためのTel URI」、RFC 3966、2004年12月。
[20] Levin, O., "H.323 Uniform Resource Locator (URL) Scheme Registration", RFC 3508, April 2003.
[20] Levin、O。、「H.323ユニフォームリソースロケーター（URL）スキーム登録」、RFC 3508、2003年4月。
[21] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[21] Mealling、M。、「IETF XMLレジストリ」、BCP 81、RFC 3688、2004年1月。
[22] Saint-Andre, P., "A Uniform Resource Identifier (URI) Scheme for the Extensible Messaging and Presence Protocol (XMPP)", Work in Progress, December 2004.
[22] Saint-Andre、P。、「拡張可能なメッセージングおよび存在プロトコル（XMPP）のユニフォームリソース識別子（URI）スキーム」、2004年12月、進行中の作業。
[23] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol (SIP)", RFC 4235, November 2005.
[23] Rosenberg、J.、Schulzrinne、H。、およびR. Mahy、「セッション開始プロトコル（SIP）の招待開始ダイアログイベントパッケージ」、RFC 4235、2005年11月。
[24] Rosenberg, J., "Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)", Work in Progress, May 2006.
[24] Rosenberg、J。、「セッション開始プロトコル（SIP）でグローバルにルーティング可能なユーザーエージェント（UA）URIS（GRUU）を取得および使用している」、2006年5月の作業。
[25] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006.
[25] Peterson、J。and C. Jennings、「セッション開始プロトコル（SIP）における認証されたアイデンティティ管理の強化」、RFC 4474、2006年8月。
Authors' Addresses
著者のアドレス
Jonathan Rosenberg Cisco Systems 600 Lanidex Plaza Parsippany, NJ 07054 US
ジョナサンローゼンバーグシスコシステム600ラニデックスプラザパルシッパニー、ニュージャージー07054米国
Phone: +1 973 952-5000
EMail: jdrosen@cisco.com
URI: http://www.jdrosen.net
Henning Schulzrinne Columbia University M/S 0401 1214 Amsterdam Ave. New York, NY 10027 US
ヘニングシュルツリンコロンビア大学M/S 0401 1214 AMSTERDAM AVE. NEW YORK、NY 10027 US
EMail: schulzrinne@cs.columbia.edu
URI: http://www.cs.columbia.edu/~hgs
Orit Levin (editor) Microsoft Corporation One Microsoft Way Redmond, WA 98052 US
Orit Levin（編集者）Microsoft Corporation One Microsoft Way Redmond、WA 98052 US
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）によって提供されます。