RFC4575 日本語訳
4575 A Session Initiation Protocol (SIP) Event Package for ConferenceState. J. Rosenberg, H. Schulzrinne, O. Levin, Ed.. August 2006. (Format: TXT=97484 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
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
コメントを求めるワーキンググループJ.ローゼンバーグの要求をネットワークでつないでください: 4575年のシスコシステムズカテゴリ: エド標準化過程H.Schulzrinneコロンビア大学のO.レヴィン、マイクロソフト社2006年8月
A Session Initiation Protocol (SIP)
Event Package for Conference State
コンファレンス状態へのセッション開始プロトコル(一口)イベントパッケージ
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(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.
このドキュメントは密結合会議のためにSession Initiationプロトコル(SIP)イベントフレームワークを使用することで会議イベントパッケージを定義します、このパッケージに通知で使用されるデータの形式と共に。 会議パッケージで、ユーザは会議Uniform Resource Identifier(URI)に加入できます。 変化に関して追加会議コンポーネントの状態の変化に関してこの会議の会員資格に任意に通知を送ります。
Rosenberg, et al. Standards Track [Page 1] RFC 4575 Conference Package August 2006
ローゼンバーグ、他 規格はコンファレンスパッケージ2006年8月にRFC4575を追跡します[1ページ]。
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
1. 序論…4 2. 用語…4 3. コンファレンスイベントパッケージ…4 3.1. イベントパッケージ名…5 3.2. フィルターにかけます。5 3.3. 購読持続時間…5 3.4. ボディーに通知してください…5 3.5. より多くのNotifierに処理する、要求を申し込んでください…6 3.6. Notifier世代、要求に通知してください…6 3.7. 加入者、処理する、要求に通知してください…6 3.8. 股状の要求の取り扱い…7 3.9. 通知の速度…7 3.10. エージェントを述べてください…7 4. コンファレンスドキュメント…7 4.1. 形式…7 4.2. 名前空間…7 4.3. Versioningします…8 4.4. 部分的な通知メカニズム…8 4.5. 要素キー…9 4.6. コヒーレント状態手順を構成します…9 5. コンファレンスデータ…11 5.1. 概要…11 5.2. <会議インフォメーション>…13 5.3. <会議記述>…14 5.3.1. <conf-uris>…14 5.3.2. urisを調整している<>…15 5.3.3. <の最大のユーザのカウントしている>…16 5.3.4. <の利用可能なメディアの>…16 5.4. <ホストインフォメーション>…17 5.4.1. <ディスプレイテキスト>…17 5.4.2. <ウェブページ>…17 5.4.3. <uris>…17 5.5. <会議州の>…17 5.5.1. <ユーザカウント>…17 5.5.2. <のアクティブな>…18 5.5.3. <は>をロックしました…18 5.6. <ユーザ>とその<ユーザ>下位要素…18 5.6.1. <ディスプレイテキスト>…19 5.6.2. <の関連aorsの>…19 5.6.3. <役割の>…19 5.6.4. <言語>…19 5.6.5. <のどっと落している焦点>…19 5.6.6. <終点>…20 5.7. <終点>…20 5.7.1. <ディスプレイテキスト>…20 5.7.2. <は>を参照しました…21
Rosenberg, et al. Standards Track [Page 2] RFC 4575 Conference Package August 2006
ローゼンバーグ、他 規格はコンファレンスパッケージ2006年8月にRFC4575を追跡します[2ページ]。
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
5.7.3. <状態>…21 5.7.4. <の接合メソッド>…22 5.7.5. <の接合インフォメーション>…23 5.7.6. <断線メソッド>…23 5.7.7. <断線インフォメーション>…23 5.7.8. <メディア>…24 5.7.9. <呼び出しインフォメーション>…24 5.8. <メディア>…24 5.8.1. <ディスプレイテキスト>…25 5.8.2. <タイプ>…25 5.8.3. <ラベル>…25 5.8.4. <src-イド>…25 5.8.5. <状態>…26 5.9. サイドバー…26 5.9.1. 近く<サイドバー審判>…26 5.9.2. 近く<サイドバーval>…26 6. XML図式…26 7. 例…35 7.1. 基本の例…35 7.2. リッシュExample…36 8. セキュリティ問題…40 8.1. 接続セキュリティ…40 8.2. 承認問題…41 9. IANA問題…41 9.1会議EventパッケージRegistration…41 9.2アプリケーション/会議インフォメーション+xml MIME Registration…42 9.3. つぼのサブ名前空間登録、…43 9.4. XML図式登録…43 9.5. URI目的サブ登録設立…44 10. 承認…45 11. 参照…45 11.1. 標準の参照…45 11.2. 有益な参照…46
Rosenberg, et al. Standards Track [Page 3] RFC 4575 Conference Package August 2006
ローゼンバーグ、他 規格はコンファレンスパッケージ2006年8月にRFC4575を追跡します[3ページ]。
1. Introduction
1. 序論
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.
Session Initiationプロトコル(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など
2. Terminology
2. 用語
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and indicate requirement levels for compliant implementations.
本書では、キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは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.
このドキュメントはConferencing Framework[16]で定義された会議用語を使用します。 さらに、「当直表」用語は、会議かサブ会議の関係者についてまとめて言及するのに使用されます。
3. Conference Event Package
3. コンファレンスイベントパッケージ
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では、会議はURIによって代表されます。 これらのURIは焦点と呼ばれる会議のすべてのユーザが互いにコミュニケートできるのを確実にするのに責任があるSIPユーザエージェント(UA)を特定します、Conferencing Framework[16]で説明されるように。 焦点には、それに関して加入者に知らせるために、会議の状態に関して十分な情報があります。
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.
事実上、会議の関係者がそうするかもしれないのが可能であるのが、別の焦点であるということです。 より完全な関与しているリストを提供して、焦点は、どっと落している会議で関与しているリストを発見するためにもう片方の焦点の会議パッケージに加入するかもしれません。 そして、通知に指定されるとしてのこのパッケージによる<のどっと落している焦点の>要素の使用でこの情報を含むことができます。
Rosenberg, et al. Standards Track [Page 4] RFC 4575 Conference Package August 2006
ローゼンバーグ、他 規格はコンファレンスパッケージ2006年8月にRFC4575を追跡します[4ページ]。
This section provides the details for defining a SIP-specific event notification package, as specified by RFC 3265 [10].
このセクションはRFC3265[10]によって指定されるようにSIP特有のイベント通知パッケージを定義するための詳細を明らかにします。
3.1. Event Package Name
3.1. イベントパッケージ名
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].
このイベントパッケージの名前は「会議」です。 このパッケージ名はRFC3265[10]で定義されるようにEventとAllow-イベントヘッダーで運ばれます。
3.2. Filtering
3.2. フィルタリング
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 通常、通知は完全な状態を含んでいません。 むしろ、彼らは変化した状態を示すだけです。 例外は登録に対応して送られたNOTIFYです。 これらのNOTIFYsは加入者によって要求された情報の完全な状態を含んでいます。
3.3. Subscription Duration
3.3. 購読持続時間
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時間です。 会議がいったん終わると、その特定の会議のすべての購読が終えられます、RFC3265[10]の定義されるとしての"noresource"の理由で。
3.4. NOTIFY Bodies
3.4. ボディーに通知してください。
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.
RFC3265[10]によると、NOTIFYメッセージは申し込まれたリソースの状態について説明するボディーを含むでしょう。 このボディーが形式がAcceptヘッダーフィールドで記載したコネである、登録、パッケージ詳細がヘッダーフィールドが省略されたAcceptであるならデフォルトとする、登録。
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
このイベントパッケージでは、通知のボディーは会議の状態について説明する会議情報ドキュメントを含みます。 すべての加入者とnotifiersはセクション9で説明された「+ アプリケーション/会議インフォメーションxml」データの形式をサポートしなければなりません。
Rosenberg, et al. Standards Track [Page 5] RFC 4575 Conference Package August 2006
ローゼンバーグ、他 規格はコンファレンスパッケージ2006年8月にRFC4575を追跡します[5ページ]。
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.
そして、5。 すなわち、Acceptヘッダーが全く登録に指定されないなら、デフォルトで、NOTIFYが「+ アプリケーション/会議インフォメーションxml」データの形式にボディーを含むよう要求してください。 Acceptヘッダーフィールドが存在しているなら、それは、「+ アプリケーション/会議インフォメーションxml」を含まなければならなくて、いかなる他のタイプも含むかもしれません。
3.5. Notifier Processing of SUBSCRIBE Requests
3.5. より多くのNotifierに処理する、要求を申し込んでください。
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.
会議情報は非常に機密の情報を含んでいます。 したがって、認証されて、次に承認の前に認可されたすべての購読SHOULD。 管理者の裁量には承認方針がいつものようにあります。
However, it is RECOMMENDED that all users in the conference be allowed to subscribe to the conference event package.
しかしながら、会議のすべてのユーザが会議イベントパッケージに加入できるのは、RECOMMENDEDです。
3.6. Notifier Generation of NOTIFY Requests
3.6. Notifier世代、要求に通知してください。
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.
通知SHOULD、新しい関係者が加わるか(すなわち、「接続されていること」に得ます)、または関係者が会議を出たら(すなわち、「切断されること」を得ます)、会議状態に生成されてください。
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.
サイドバー当直表SHOULDの変化は、焦点によって彼らの関係者に報告されて、ローカルの方針を条件として他のものに報告されるかもしれません。
Changes in conference identifiers and service URIs SHOULD be reported by the focus to the conference package subscribers.
URI SHOULDを会議識別子で変えて、調整してください。焦点で、会議のパッケージ加入者に報告されます。
Changes in other conference state information MAY be reported by the focus to the conference package subscribers.
他の会議州の情報における変化は焦点によって会議のパッケージ加入者に報告されるかもしれません。
3.7. Subscriber Processing of NOTIFY Requests
3.7. 加入者、処理する、要求に通知してください。
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イベントフレームワークは、パッケージが加入者がどうNOTIFY要求をどんなパッケージ特有の道とも、特に処理するかを指定すると予想します、それはどう、申し込まれたリソースの状態の論理的な視点を構成するというNOTIFY要求を使用するか。
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.
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.
Rosenberg, et al. Standards Track [Page 6] RFC 4575 Conference Package August 2006
Rosenberg, et al. Standards Track [Page 6] RFC 4575 Conference Package August 2006
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.
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.
3.8. Handling of Forked Requests
3.8. Handling of Forked Requests
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.
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.
3.9. Rate of Notifications
3.9. Rate of Notifications
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.
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.
3.10. State Agents
3.10. State Agents
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.
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.
4. Conference Document
4. Conference Document
4.1. Format
4.1. Format
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].
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].
4.2. Namespace
4.2. Namespace
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'
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'
Rosenberg, et al. Standards Track [Page 7] RFC 4575 Conference Package August 2006
Rosenberg, et al. Standards Track [Page 7] RFC 4575 Conference Package August 2006
defined by [6] and extended by RFC 3688 [21]. This URN is as follows:
defined by [6] and extended by RFC 3688 [21]. This URN is as follows:
urn:ietf:params:xml:ns:conference-info
urn:ietf:params:xml:ns:conference-info
4.3. Versioning
4.3. Versioning
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.
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.
The 'version' attribute MUST be included in the root <conference-info> element.
The 'version' attribute MUST be included in the root <conference-info> element.
4.4. Partial Notifications Mechanism
4.4. Partial Notifications Mechanism
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.
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.
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.
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.)
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>
o Element <conference-info> o Element <users> o Element <user> o Element <endpoint> o Element <sidebars-by-val> o Element <sidebars-by-ref>
Rosenberg, et al. Standards Track [Page 8] RFC 4575 Conference Package August 2006
Rosenberg, et al. Standards Track [Page 8] RFC 4575 Conference Package August 2006
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".
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".
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.
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.
4.5. Element Keys
4.5. Element Keys
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.
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.
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, 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.
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.
Below is the list of elements (subject to partial notifications of their parent elements) with their keys as defined by this specification:
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 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>
4.6. Constructing Coherent State Procedure
4.6. Constructing Coherent State Procedure
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
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
Rosenberg, et al. Standards Track [Page 9] RFC 4575 Conference Package August 2006
Rosenberg, et al. Standards Track [Page 9] RFC 4575 Conference Package August 2006
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.
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.
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.
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.
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.
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.
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.
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.
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,
For each sub-element of the <conference-info> element in the received document,
1. If the element contains "full" state, the whole local element
content is flushed and repopulated from the document.
1. If the element contains "full" state, the whole local element content is flushed and repopulated from the document.
2. Otherwise, if the element contains "deleted" state, the whole
element MUST be removed from the local content.
2. Otherwise, if the element contains "deleted" state, the whole element MUST be removed from the local content.
3. Otherwise, if the element contains "partial" state:
3. Otherwise, if the element contains "partial" state:
Rosenberg, et al. Standards Track [Page 10] RFC 4575 Conference Package August 2006
Rosenberg, et al. Standards Track [Page 10] RFC 4575 Conference Package August 2006
3.1. For elements with keys, the subscriber compares the keys
received in the update with the keys in the local tables.
3.1. For elements with keys, the subscriber compares the keys received in the update with the keys in the local tables.
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. 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.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. 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.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. 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.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. For each non-atomic element with the state attribute set to "partial", the algorithm is applied recursively starting from step 3.1.
5. Conference Data
5. Conference Data
5.1. Overview
5.1. Overview
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.
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.
Rosenberg, et al. Standards Track [Page 11] RFC 4575 Conference Package August 2006
Rosenberg, et al. Standards Track [Page 11] RFC 4575 Conference Package August 2006
conference-info
|
|-- conference-description
|
|-- host-info
|
|-- conference-state
|
|-- users
| |-- user
| | |-- endpoint
| | | |-- media
| | | |-- media
| | | |-- call-info
| | |
| | |-- endpoint
| | |-- media
| |-- user
| |-- endpoint
| |-- media
|
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
|-- 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>,
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>,
Rosenberg, et al. Standards Track [Page 12] RFC 4575 Conference Package August 2006
Rosenberg, et al. Standards Track [Page 12] RFC 4575 Conference Package August 2006
<host-info>, <endpoint>, and <media> are intended for display to human subscribers only.
<host-info>, <endpoint>, and <media> are intended for display to human subscribers only.
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.
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.
Following sections describe the XML schema in more detail.
5.2. <conference-info>
5.2. <conference-info>
A conference information document begins with the root element tag <conference-info> of conference-type.
A conference information document begins with the root element tag <conference-info> of conference-type.
The following attributes are defined for <conference-info>:
The following attributes are defined for <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である、登録、会議を得るには、情報をパッケージしてください。 SIP手段とセクション5.3.1未満に従って会議にアクセスするのに使用されるためにURIの1つとしてこのURIを記載できることに注意してください。
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.
バージョン: インフォメーション>要素が根の<会議と共に使用される状態で、この属性は適切に受信された通知を注文するドキュメント、およびそれが会議情報でなければならないことの受取人を許容します。 バージョン番号は購読の中で見られた32ビットの単調に増加する整数です。 加入者に送られて、会議ドキュメント状態で変化を報告して、サーバはそれぞれの通知(完全で、部分的で、削除された)のバージョン番号を増加しなければなりません。 それぞれの部分的な通知において、バージョン番号を1つ増強しなければなりません。 会議状態の変化が全く中間で起こらなかったなら同じ対話の上の部分的な通知とその後の完全な通知が同じバージョン番号を含むかもしれないことに注意してください。
Rosenberg, et al. Standards Track [Page 13] RFC 4575 Conference Package August 2006
ローゼンバーグ、他 規格はコンファレンスパッケージ2006年8月にRFC4575を追跡します[13ページ]。
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.
<会議、-インフォメーション>要素は<会議記述>、<ホストインフォメーション>、<会議州の>、<ユーザ>、近く<サイドバー近く審判>と<サイドバーvalな>子供要素から成ります。 「完全な」会議ドキュメントは<会議記述>と<ユーザ>子供要素を少なくとも含まなければなりません。
Following sections describe these elements in detail. The full XML schema is provided in Section 6.
以下の章は詳細にこれらの要素について説明します。 完全なXML図式をセクション6に提供します。
5.3. <conference-description>
5.3. <会議記述>。
The <conference-description> element describes the conference as a whole.
<会議、-記述>要素は全体で会議について説明します。
The child elements <display-text>, <subject>, <free-text>, and <keywords> are used to describe the conference content:
子供要素の<ディスプレイテキスト>、<の対象の>、<の無料のテキスト>、および<キーワード>は会議内容について説明するのに使用されます:
<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>とurisを調整している<>は会議関連のURIについて説明するのに使用されます。 <の最大のユーザのカウントしている>と<の利用可能なメディアの>は、総合的な特性について説明するのに使用されます。
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.
以下のセクションはさらに詳細に残っている要素について説明します。 他の下位要素は将来、<会議記述>を広げることができます。
5.3.1. <conf-uris>
5.3.1. <conf-uris>。
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>下位要素に含まれています。
Rosenberg, et al. Standards Track [Page 14] RFC 4575 Conference Package August 2006
ローゼンバーグ、他 規格はコンファレンスパッケージ2006年8月にRFC4575を追跡します[14ページ]。
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.
<エントリー>要素は人間の消費で意味された原文の記述を提供するテキストを表示している<>下位要素を含むかもしれません。
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:
それぞれの<エントリー>要素SHOULDは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体系に関する例は一口を含んでいます: 一口: [8]、xmpp: [22]、h323: [20]、およびtel: [19] URI。 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に新しい値を定義して、それらを登録するかもしれません。
5.3.2. <service-uris>
5.3.2. urisを調整している<>。
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.
この要素は会議に利用可能な補助のサービスについて説明します。 <が>を会議してurisするように、それぞれ特定の会議に利用可能な異なったサービスにアクセスするのに使用されるべきURIを含んでいて、この要素は1セットの<エントリー>子供要素を含んでいます。 URIの値は、会議文脈でユニークでなければならなく、<uri>下位要素に含まれています。
An <entry> element MAY contain the <display-text> sub-element that provides a textual description meant for user consumption.
<エントリー>要素はユーザ消費で意味された原文の記述を提供するテキストを表示している<>下位要素を含むかもしれません。
Each <entry> element SHOULD contain a <purpose> sub-element. The currently defined <purpose> values to be used with the <service-uris> are the following:
それぞれの<エントリー>要素SHOULDは<目的>下位要素を含んでいます。 >がurisを調整している<>と共に使用されているのが、以下であるということになるように評価する現在定義された<目的:
web-page: Indicates the web page containing the additional
information about the conference.
ウェブページ: 会議に関する追加情報を含むウェブページを示します。
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でしょう。
Rosenberg, et al. Standards Track [Page 15] RFC 4575 Conference Package August 2006
ローゼンバーグ、他 規格はコンファレンスパッケージ2006年8月にRFC4575を追跡します[15ページ]。
Future extensions to this schema may define new values and register them with IANA under the registry established by this specification.
この図式への今後の拡大は、この仕様で確立された登録の下のIANAに新しい値を定義して、それらを登録するかもしれません。
5.3.3. <maximum-user-count>
5.3.3. <の最大のユーザのカウントしている>。
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がパワーを処理して、規則を認可して。
5.3.4. <available-media>
5.3.4. <の利用可能なメディアの>。
This element contains a sequence of <entry> child elements of conference-medium-type, each being indexed by the attribute 'label'.
属性'ラベル'によってそれぞれ索引をつけられて、この要素は会議ミディアム・タイプの<エントリー>子供要素の系列を含んでいます。
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].
'ラベル'属性はストリーム識別子が会議サーバで割り当てたメディアです: 値は<会議インフォメーションでユニークになるでしょう。>文脈。 この属性の値は[17]で定義されたSession記述プロトコル(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
<状態>: この要素は会議の参加者にとって、利用可能なメディアストリームの利用可能な状態を示します。 例えば、これはメディアストリームの状態でしょう、'ダイヤルアウト'シナリオで。(ストリームは焦点によって提供されるでしょう)。 使用の正常なSIPはメカニズムに提供するか、または答えます。(ともにダイヤルインとダイヤルアウトシナリオでRFC3264[9])で定義されて、関係者はもちろん利用可能なストリームの部分集合しか確立できません(すなわち、ストリームを一方向だけに要求するか、または受け入れてください、両方の方向が利用可能であるなら)。 有効値はSDP[3]の「sendonlyに」「recvonlyである」か、定義されるとして「不活発である」"sendrecv"です、そして、それは、より遅れています。
Rosenberg, et al. Standards Track [Page 16] RFC 4575 Conference Package August 2006
ローゼンバーグ、他 規格はコンファレンスパッケージ2006年8月にRFC4575を追跡します[16ページ]。
revision(s). (Note that the value specifies the direction from
the participants' point of view.)
改正。 (値が関係者の観点から方向を指定することに注意してください。)
5.4. <host-info>
5.4. <ホストインフォメーション>。
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:
この要素は、会議を主催しながら、実体の情報を含んでいます。 この情報は会議起動の前に設定されます、そして、それは会議生涯めったに変えられません、全体の会議が別の実体によって接待されるので動かされない場合。 ホスト情報は以下の要素から成ります:
5.4.1. <display-text>
5.4.1. <ディスプレイテキスト>。
This element contains display text describing the entity hosting the conference.
この要素は会議を主催しながら実体について説明するディスプレイテキストを含んでいます。
5.4.2. <web-page>
5.4.2. <ウェブページ>。
This element contains HTTP: or HTTPS: URI of a web page describing either the conference service or the user hosting the conference.
この要素はHTTPを含んでいます: HTTPS: 会議サービスか会議を主催するユーザのどちらかについて説明する1ウェブページのURI。
5.4.3. <uris>
5.4.3. <uris>。
This element contains a set of <entry> child elements, each containing the URI value and optionally its description.
それぞれ任意にURI値を含んでいて、この要素は1セットの<エントリー>子供要素を含んでいます。その記述。
5.5. <conference-state>
5.5. <会議州の>。
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.
会議ドキュメントにこの要素を含んでいることによって、サーバは総合的な会議情報における変化に関して加入者に知らせることができます。 <は、>子供要素が以下で説明されると会議して述べます。
5.5.1. <user-count>
5.5.1. <ユーザカウント>。
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>の会議ドキュメントを通して発行されるように会議に参加したユーザの総合的な数を表します。 この数が必ず合うのが必要であるというわけではなく、<ユーザ>コンテナのエントリーの数を超えるかもしれないことに注意してください。 例えば、講義シナリオでは、大きい会議通知は<ユーザ>要素のすべての関係者を含まないかもしれませんが、代わりにパネリストかスピーカーだけを報告してください。
Rosenberg, et al. Standards Track [Page 17] RFC 4575 Conference Package August 2006
ローゼンバーグ、他 規格はコンファレンスパッケージ2006年8月にRFC4575を追跡します[17ページ]。
5.5.2. <active>
5.5.2. <のアクティブな>。
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>のアクティブな、しかし、呼んでいる1つがクライアントと焦点とのシグナリングセッションのうまくいっている設立と会議のうまくいっている接合をもたらすということです。
5.5.3. <locked>
5.5.3. <は>をロックしました。
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).
このブール要素は、会議が現在ロックされるかどうか言います。 このような関係においては会議当直表を追加できない「ロックされた」手段(関係者は、いなくなるか、または会議から外されるかもしれませんが)。
5.6. <users> and Its <user> Sub-elements
5.6. <ユーザ>とその<ユーザ>下位要素
The <users> element is a container of <user> child elements, each describing a single participant in the conference.
それぞれ会議の独身の関係者について説明して、<ユーザ>要素は<ユーザ>子供要素のコンテナです。
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を含んでいます。 これが論理的な識別子である、どれが呼び出しシグナリングに対応しているかが関係者のアイデンティティを認証しました。 '実体'値は会議のすべての関係者の中でユニークであるに違いありません。 焦点が、何人かの関係者に関してこの情報(例えば、ローカルの方針かセキュリティ理由による)を明らかにしないと決めるなら、RFC2606[5]の定義に従って、ユーザユリのホスト部分は.invalidトップ・レベル・ドメイン(TLD)を使用しなければなりません。 焦点もURIのユーザ部分を構成しなければならないので、URIは同じドメインのすべての関係者の中でユニークです。 例えば、コンベンション
"AnonymousX" <sip:anonymousX@anonymous.invalid>
"AnonymousX"<一口: anonymousX@anonymous.invalid 、gt。
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:
SHOULD、RFC3323[11]の匿名のURIを生成するためのガイドラインによると、プライバシーを要求する関係者には、使用されてください。 SIP[25]でAuthenticated Identity ManagementのためのEnhancementsに関連して使用されていて、以下のコンベンションを使用できる時などの異なった場合でそれに注意してください:
"AnonymousX" <sip:anonymousX@example.com>
"AnonymousX"<一口: anonymousX@example.com 、gt。
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").
州: この属性は、ドキュメントが全体のユーザー情報(「完全な」)か前のドキュメント以来変化している情報(「部分的な」)だけを含んでいるかどうか、またはユーザが会議(「削除される」)から外されたかどうかを示します。
Rosenberg, et al. Standards Track [Page 18] RFC 4575 Conference Package August 2006
ローゼンバーグ、他 規格はコンファレンスパッケージ2006年8月にRFC4575を追跡します[18ページ]。
The following child elements are defined for <user> element:
以下の子供要素は<ユーザ>要素のために定義されます:
5.6.1. <display-text>
5.6.1. <ディスプレイテキスト>。
This element is used to display the user-friendly name in the conference.
この要素は、会議でユーザフレンドリーな名前を表示するのに使用されます。
5.6.2. <associated-aors>
5.6.2. <の関連aorsの>。
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>.
この要素は<ユーザ>に関連している追加している('実体'への)URIを含んでいます。 そうでなければ、手動でシグナリングの間の管理者表示による論理的な協会に提供された実体が独立していたなら、通常、この情報はそうするでしょう。 例えば、<ユーザの'実体'>はGlobally Routable User URI(GRUU)[24]を含んでいるか、そして、tel: URI RFC3966[19]、これらのデバイスを使用する人のRecord(AOR)のAddressと共にこの分野に居住するのが役に立つだろう、それぞれが独立している<ユーザとして>を表しました。
5.6.3. <roles>
5.6.3. <役割の>。
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.
この要素は会議でユーザの役割について説明する1セットの人間読み込み可能なストリングを含むかもしれません。 この情報が人間の消費だけで適切であることに注意してください。 この仕様は可能な会議の役割のセットかそれぞれに関連している意味論を定義しません。 将来の会議仕様がこれらと対応する図式拡大を定義すると適宜予想されます。
5.6.4. <languages>
5.6.4. <言語>。
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.
この要素はそれぞれユーザに解釈された言語を含む空間によって切り離されたトークンのリストを含んでいます。 この情報を呼び出しシグナリングで自動的に学習するか、または関係者単位で手動で設定できます。
5.6.5. <cascaded-focus>
5.6.5. <のどっと落している焦点>。
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 Conferencing Framework[16]によると、このパッケージはピアツーピア(すなわち、「平坦な」)の表現のために焦点滝だけを許容します。 単独でパッケージに提供された情報から実際の滝のグラフを推論できません。 高度なアプリケーションは、このパッケージとそれぞれのどっと落している焦点のDialogパッケージ[23]の両方に加入して、関連情報を関連させることによって、グラフを作図できます。
Rosenberg, et al. Standards Track [Page 19] RFC 4575 Conference Package August 2006
ローゼンバーグ、他 規格はコンファレンスパッケージ2006年8月にRFC4575を追跡します[19ページ]。
5.6.6. <endpoint>
5.6.6. <終点>。
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つ以上の<終点>要素を含んでいることによって、サーバは会議に参加しながら、ユーザのデバイスとシグナリングおよそセッション必要なレベルの詳細(状態、メディアストリーム、およびアクセス情報を含んでいる)を明らかにすることができます。
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.
認証が終点単位で実行される会議システム、(むしろ、ユーザ、)、焦点は一般的なユーザの下の複数の終点の論理的な協会に気づかない場合があります。 この場合、それ自身の<終点>下位要素が会議ドキュメントにある状態で、各終点は別々の<ユーザ>として現れるでしょう。
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.
異なった場合では、焦点は、全体で他の加入者からの関係者の複数の終点とシグナリングおよそセッション(例えば、プライバシーに関する方針のため)情報を保護するのを選ぶかもしれません。 そうするために、焦点はただ一つの<終点>要素の下で複数のシグナリングセッションの情報に集められるかもしれません。 この場合詳細な呼び出しシグナリング情報(インフォメーションと呼んでいる<>下位要素で、表される)が含まれないことに注意してください。
5.7. <endpoint>
5.7. <終点>。
This section describes the <endpoint> element in more detail.
このセクションはさらに詳細に<終点>要素について説明します。
The following attributes are defined for the <endpoint> element:
以下の属性は<終点>要素のために定義されます:
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.
実体: サーバは親<ユーザ>の下にそれぞれの<終点>要素を含んでいるのに、主要な'実体'を生成しなければなりません、値がユーザ文脈でユニークであるように。 SIP用語で、これはContactユリ、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:
以下の子供要素は<終点>要素のために定義されます:
5.7.1. <display-text>
5.7.1. <ディスプレイテキスト>。
This element contains the display text for the endpoint.
この要素は終点へのディスプレイテキストを含んでいます。
Rosenberg, et al. Standards Track [Page 20] RFC 4575 Conference Package August 2006
ローゼンバーグ、他 規格はコンファレンスパッケージ2006年8月にRFC4575を追跡します[20ページ]。
5.7.2. <referred>
5.7.2. <は>を参照しました。
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ユーザはREFERを焦点に送りました)。 それは以下の下位要素を含むかもしれません:
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)の形式であったなら会議とSHOULDを参照された日時を含んでいます。 例えば
<when>2005-03-04T20:00:00Z</when>
<、>であることのいつ>2005-03-04T20:00:00Z</
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,
理由: この要素は終点は会議を参照された理由を含んでいます。 RFC3326[12]によって定義された書式で情報を含むのは、RECOMMENDEDです。 例えば
<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].
: この要素は終点が会議を参照した実体のURIを含んでいます。 SIPの場合では、RFC3892[15]で定義された近くReferredヘッダーからそれに居住するでしょう。
5.7.3. <status>
5.7.3. <状態>。
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
焦点を通って音を消される: アクティブなシグナリング対話は終点と焦点の間に存在しています、そして、終点は会議を「聴くことができます」が、終点のメディアは会議に複雑ではありません。 注意
Rosenberg, et al. Standards Track [Page 21] RFC 4575 Conference Package August 2006
ローゼンバーグ、他 規格はコンファレンスパッケージ2006年8月にRFC4575を追跡します[21ページ]。
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.
他のもの(声かIMなどの)がまだ活発である場合がある間時々、焦点(劣った品質ビデオなどの)で終点メディアストリームの部分集合に音を消すことができます。 この場合、「集められた」終点接続性<状態>が最も活動的なメディアの状態を反映するのは、RECOMMENDEDです。
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.
警告します: 外国行きの呼び出しのためにPublic Switched Telephone Network(PSTN)ALERTINGかSIP180Ringingを返しました。 終点は警告されています。
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では、DISCONNECTかBYEを終点に送りました)。
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.
定義された一時的な状態(例えば、切断する警告など)が多くのトラフィックを生成するかもしれないことに注意してください。 したがって、実装は、これらの状態に関する通知を確信している関係者だけに生成するか、またはローカルの方針を条件として彼らを全く生成しないのを選ぶかもしれません。
5.7.4. <joining-method>
5.7.4. <接合メソッド>。
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はINVITEを焦点に送った)にダイヤルしました。(それは、うまくいっている対話設立をもたらしました)。
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では、焦点はうまくいっているINVITEを終点に送りました)。
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が会議焦点として機能するときだけ、この状態は使用されています。
Rosenberg, et al. Standards Track [Page 22] RFC 4575 Conference Package August 2006
ローゼンバーグ、他 規格はコンファレンスパッケージ2006年8月にRFC4575を追跡します[22ページ]。
5.7.5. <joining-info>
5.7.5. <接合インフォメーション>。
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)であったなら会議とSHOULDに参加した日時を含んでいます。
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,
理由: この要素は終点が会議に参加した理由を含んでいます。 RFC3326[12]によって定義された書式で情報を含むのは、RECOMMENDEDです。 例えば
<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.
: この要素は終点が会議に参加した実体のURIを含んでいます。
5.7.6. <disconnection-method>
5.7.6. <断線メソッド>。
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では、終点はBYEを送って、その結果、会議を出ました。
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では、会議からその人を追放して、焦点はBYEを終点に送りました。 あるいはまた、終点は、会議にダイヤルしようとしましたが、ローカルの方針のため焦点によって拒絶されました。
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応答で応じました。
5.7.7. <disconnection-info>
5.7.7. <断線インフォメーション>。
This element contains information about the endpoint's departure from the conference and MAY contain the following sub-elements:
この要素は、会議からの終点の出発の情報を含んでいて、以下の下位要素を含むかもしれません:
Rosenberg, et al. Standards Track [Page 23] RFC 4575 Conference Package August 2006
ローゼンバーグ、他 規格はコンファレンスパッケージ2006年8月にRFC4575を追跡します[23ページ]。
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)であったなら会議とSHOULDを退職した日時を含んでいます。
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,
理由: この要素は終点が会議を退職した理由を含んでいます。 知られていて重要であるときに、呼び出しシグナリングによってRFC3326[12]によって定義された書式で伝えられるか、または報告される情報を含むのは、RECOMMENDEDです。 例えば
<reason>Reason: SIP;cause=415;text="Unsupported Media Type"</reason>
<理由>理由: 一口; 原因=415; テキストが等しい、「サポートされないメディアは「</理由>」をタイプします。
by: This element contains the URI of the entity that caused the
endpoint to depart the conference.
: この要素は終点が会議を退職した実体のURIを含んでいます。
5.7.8. <media>
5.7.8. <メディア>。
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].
この要素は、ただ一つのメディアストリームの情報を含んでいて、焦点と<終点>の間で確立されるそれぞれのメディアストリームのために含まれています。 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.
終点のインフォメーションと呼んでいる<>下位要素がドキュメントにサーバによって含まれていないなら、一般的な<終点>の下に記載されたメディアストリームが別々のシグナリングセッションで確立されたのが、可能であることに注意してください。
5.7.9. <call-info>
5.7.9. <呼び出しインフォメーション>。
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.
>要素が提供する<呼び出しインフォメーションは関係者と焦点の間で維持される呼び出しのための呼び出しシグナリング情報を詳しく述べました。 他の関係者にこの情報を明らかにする前に、プライバシーに関する方針に相談しなければなりません。
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対話識別子を含んでいます。 要素はタグ>からの下位要素<ディスプレイテキスト>、<呼び出しイド>、タグ>への<、<を含んでいます。
In future, the <call-info> element can be expanded to include call signaling protocol information for other protocols besides SIP.
これから、SIP以外に他のプロトコルのための呼び出しシグナリングプロトコル情報を含むようにインフォメーションと呼んでいる<>要素は広げることができます。
5.8. <media>
5.8. <メディア>。
This section describes the <media> element in more detail.
このセクションはさらに詳細に<メディア>要素について説明します。
A single 'id' attribute is defined for this element. This is the media stream identifier being generated by the server such that its
ただ一つの'イド'属性はこの要素のために定義されます。 これ、サーバによって生成されるメディアストリーム識別子がそのようである、それ、それ
Rosenberg, et al. Standards Track [Page 24] RFC 4575 Conference Package August 2006
ローゼンバーグ、他 規格はコンファレンスパッケージ2006年8月にRFC4575を追跡します[24ページ]。
value is unique in the endpoint context. This attribute is the key to refer to a particular media stream in the conference document.
値は終点文脈でユニークです。 この属性は会議ドキュメントの特定のメディアストリームについて言及するキーです。
The following child elements are defined for <media>:
以下の子供要素は<メディア>のために定義されます:
5.8.1. <display-text>
5.8.1. <ディスプレイテキスト>。
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」)に対応しています。
5.8.2. <type>
5.8.2. <タイプ>。
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つであるに違いありません。
5.8.3. <label>
5.8.3. <ラベル>。
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.
<ラベル>要素は、会議でこのストリームのためのユニークな識別子をすべてのストリームまで運んで、焦点によって割り当てられます。 この要素の価値は[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では、説明される)が会議ドキュメントに含まれているなら、この要素の価値は<の利用可能なメディアの>コンテナの対応するメディアストリーム<エントリー>の'ラベル'値と等しいに違いありません。
5.8.4. <src-id>
5.8.4. <src-イド>。
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イドの>要素はメディアの実際の源の情報を運びます。 例えば、レアル-時間Transportプロトコル(RTP)/RTP Controlプロトコル(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)."
RTP/RTCP[13]によると、RTPミキサーが貢献しているソース(CSRC)に識別子のリストを生成すると、それは特定のパケットの世代に貢献したソースに関するSSRC識別子のリストをそのパケットのRTPヘッダーに挿入します。 RFC3550[13]からの引用文は以下の通り説明します: 「例のアプリケーションはミキサーがスピーチが出発しているパケットを作り出すために結合されたすべての話し手を示すところの電話による会議です、受信機が現在の話し手を示すのを許容して、すべてのオーディオパケットが同じSSRC識別子(ミキサーのもの)を含んでいますが。」
Rosenberg, et al. Standards Track [Page 25] RFC 4575 Conference Package August 2006
ローゼンバーグ、他 規格はコンファレンスパッケージ2006年8月にRFC4575を追跡します[25ページ]。
If an RTP mixer compliant to the above is used, participants can perform an SSRC to user mapping and identify "a current speaker".
上記で言いなりになっているRTPミキサーが使用されているなら、関係者は、ユーザマッピングにSSRCを実行して、「現在のスピーカー」を特定できます。
5.8.5. <status>
5.8.5. <状態>。
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".
要素<状態>はSDP[3]とその後の改正で定義されるようにメディアストリームの両方の方向に状態を示して、「sendonlyであっ」て、「recvonlyである」"sendrecv"か「不活発」に値を持っています。 値が関係者の観点から方向を指定することに注意してください。 例えば、音を消された関係者のストリームには、"recvonly"の値があるでしょう。
5.9. Sidebars
5.9. サイドバー
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.
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.
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.
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.
5.9.1. <sidebars-by-ref>
5.9.1. <sidebars-by-ref>
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.
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.
5.9.2. <sidebars-by-val>
5.9.2. <sidebars-by-val>
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.
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.
6. XML Schema
6. XML Schema
<?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"
<?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"
Rosenberg, et al. Standards Track [Page 26] RFC 4575 Conference Package August 2006
Rosenberg, et al. Standards Track [Page 26] RFC 4575 Conference Package August 2006
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"/>
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"/>
Rosenberg, et al. Standards Track [Page 27] RFC 4575 Conference Package August 2006
Rosenberg, et al. Standards Track [Page 27] RFC 4575 Conference Package August 2006
</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: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">
Rosenberg, et al. Standards Track [Page 28] RFC 4575 Conference Package August 2006
Rosenberg, et al. Standards Track [Page 28] RFC 4575 Conference Package August 2006
<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"
<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"
Rosenberg, et al. Standards Track [Page 29] RFC 4575 Conference Package August 2006
Rosenberg, et al. Standards Track [Page 29] RFC 4575 Conference Package August 2006
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"
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"
Rosenberg, et al. Standards Track [Page 30] RFC 4575 Conference Package August 2006
Rosenberg, et al. Standards Track [Page 30] RFC 4575 Conference Package August 2006
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="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"
Rosenberg, et al. Standards Track [Page 31] RFC 4575 Conference Package August 2006
Rosenberg, et al. Standards Track [Page 31] RFC 4575 Conference Package August 2006
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
-->
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 -->
Rosenberg, et al. Standards Track [Page 32] RFC 4575 Conference Package August 2006
Rosenberg, et al. Standards Track [Page 32] RFC 4575 Conference Package August 2006
<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>
<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>
Rosenberg, et al. Standards Track [Page 33] RFC 4575 Conference Package August 2006
Rosenberg, et al. Standards Track [Page 33] RFC 4575 Conference Package August 2006
<!--
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>
<!-- 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>
Rosenberg, et al. Standards Track [Page 34] RFC 4575 Conference Package August 2006
Rosenberg, et al. Standards Track [Page 34] RFC 4575 Conference Package August 2006
7. Examples
7. Examples
7.1. Basic Example
7.1. Basic Example
The following is an example of a full conference information document:
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>
<?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>
Rosenberg, et al. Standards Track [Page 35] RFC 4575 Conference Package August 2006
Rosenberg, et al. Standards Track [Page 35] RFC 4575 Conference Package August 2006
<!--
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>
<!-- 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>
7.2. Rich Example
7.2. Rich Example
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 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
Rosenberg, et al. Standards Track [Page 36] RFC 4575 Conference Package August 2006
Rosenberg, et al. Standards Track [Page 36] RFC 4575 Conference Package August 2006
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.
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.
<?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>
<?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>
Rosenberg, et al. Standards Track [Page 37] RFC 4575 Conference Package August 2006
Rosenberg, et al. Standards Track [Page 37] RFC 4575 Conference Package August 2006
<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
<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
Rosenberg, et al. Standards Track [Page 38] RFC 4575 Conference Package August 2006
Rosenberg, et al. Standards Track [Page 38] RFC 4575 Conference Package August 2006
-->
<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>
--><終点実体=「一口: bob@pc33.example.com 」、gt;、><理由>専門家であるときに、>2005-03-04T20:00:00Z</が>一口で</理由><を必要としたとき、<ディスプレイテキスト>ボブのLaptop</ディスプレイ-テキスト><は><を参照しました: mike@example >2005-03-04T20:00:00Z</であるときに、>一口による><理由>招待</理由><であるときに、状態><接合</メソッドが>であると切断する></参照された><状態>のそばのcom</は-外で</接合-メソッド><接合インフォメーション><にダイヤルしました: mike@example ></接合-インフォメーション><断線メソッド>の起動させられた</断線-メソッド><断線インフォメーション>によるcom</
<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
CALL INFO--タグ>vav738dvbs</からのタグ>一口></呼び出し</インフォメーション></終点></ユーザ></ユーザ> @!へのタグ??からタグ?8954jgjg8432?/までの??呼び出しインフォメーション??一口??ディスプレイテキスト?の完全なインフォメーション?/ディスプレイ-テキスト??呼び出しイド?hsjh8980vhsb78呼び出し?/イド??--SIDEBARS BY REFERENC?br />
Rosenberg, et al. Standards Track [Page 39] RFC 4575 Conference Package August 2006
-->
<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"
状態が「部分的な「><ユーザ><ユーザ実体=」一口: bob@example.com 」/と等しい、gt;、<ユーザ実体=「一口: mark@example.com 」/、gt;、<ユーザ実体=「一口: dan@example.com 」/、gt;、</ユーザ>近くエントリー></サイドバー</val></会議-インフォメーション>。
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>
8. セキュリティ問題
8. Security Considerations
会議州の情報の購読は非常に機密の情報を明らかにすることができます。 この理由で、焦点が認証と会議情報保護に強い手段を使用して、本書では定義された会議通知メカニズムを使用するとき包括的な承認規則を適用するのは、RECOMMENDEDです。 以下のセクションはさらに詳細にそれぞれのこれらの局面について論ずるでしょう。
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.
8.1. 接続セキュリティ
8.1. Connection Security
焦点が正常なSIP認証機構を使用することで会議のパッケージ加入者を認証するのは、RECOMMENDEDです、RFC3261[8]のセクション22で定義されるDigestなどのように。
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].
会議情報を伝えるのに使用されるメカニズムは、保全とSHOULDが秘密に情報を確実にするのを確実にしなければなりません。 これらを達成してください、終わりから終わりへのSIP暗号化メカニズム
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,
Rosenberg, et al. Standards Track [Page 40] RFC 4575 Conference Package August 2006
such as S/MIME described in Section 26.2.4 of RFC 3261 [8], SHOULD be used.
終わりから終わりへの強いセキュリティが、(such as above)が利用可能でないことを意味するなら、ホップごとの互いのTransport Layer Security(TLS)認証と暗号化メカニズムがセクション26.2.2で説明した焦点使用が「URI体系をちびちび飲むこと」が、RECOMMENDEDであり、セクション26.3.2はRFC3261[8]の.2「Interdomain要求」です。
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].
8.2. 承認問題
8.2. Authorization Considerations
概して、会議アプリケーションは承認決定に関して非常に心配しています。 そのような承認規則を確立して、実施するためのメカニズムはSIP Conferencing Framework[16]中の主要な概念です。 会議パッケージを使用することで会議の情報の大部分を提示できるので、承認規則の多くが直接この仕様に適用されます。 その結果、通知サーバは、会議、個人的なアクセス権などにおける加入者の役割を条件として異なった会議情報が視点であると異なった加入者に生成することができなければなりません。 - ローカルの承認方針と規則を条件としたすべて。
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では、これはRFC3323[11]で説明されたPrivacyヘッダーフィールドを使用し終わることができます。 いいえ、関係者がプライバシーを要求することでのアイデンティティ情報SHOULD。どんな含まれているURI(例えば、Record、Contact、またはGRUUのAddress)でも焦点で、明らかにされてください。 これらのケースにおいて、メソッドがこのドキュメントのセクション5.6に概説した匿名のURI世代に続かなければなりません。
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.
9. IANA問題
9. IANA Considerations
このドキュメントは、SIPイベントパッケージ、新しいMIMEの種類、アプリケーション/会議インフォメーション+xml、新しいXML名前空間、および新しいXML図式を登録して、既存の登録の下のサブ登録「URI目的」を作成します: http://www.iana.org/assignments/sip-parameters 。
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.
9.1. 会議EventパッケージRegistration
9.1. conference Event Package Registration
この仕様はRFC3265[10]で定義された登録手順に基づいてイベントパッケージを登録します。 ↓これはそのような登録に必要である情報です:
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:
Rosenberg, et al. Standards Track [Page 41] RFC 4575 Conference Package August 2006
Package Name: conference
パッケージかテンプレートパッケージ: これはパッケージです。
Package or Template-Package: This is a package.
発行されたドキュメント: RFC4575
Published Document: RFC 4575
連絡する人: IETF SIPPING Working Group <sipping@ietf.org 、gt;、 IESG <iesg@ietf.org によって指定される、gt。
Person to Contact: IETF SIPPING Working Group <sipping@ietf.org>, as
designated by the IESG <iesg@ietf.org>
9.2. アプリケーション/会議インフォメーション+xml MIME Registration
9.2. application/conference-info+xml MIME Registration
MIMEメディア型名: アプリケーション
MIME media type name: application
MIME「副-タイプ」は以下を命名します。 会議インフォメーション+xml
MIME subtype name: conference-info+xml
義務的なパラメタ: なし
Mandatory parameters: none
任意のパラメタ: RFC3023の指定されるとしてのcharsetパラメタアプリケーション/xmlと同じこと[7]
Optional parameters: Same as charset parameter application/xml as
specified in RFC 3023 [7]
問題をコード化します: 指定されるとしてアプリケーション/xmlの問題をコード化するのとRFC3023の同じこと[7]
Encoding considerations: Same as encoding considerations of
application/xml as specified in RFC 3023 [7]
セキュリティ問題: RFC3023[7]のセクション10とこの仕様のセクション8を見てください。
Security considerations: See Section 10 of RFC 3023 [7] and
Section 8 of this specification
相互運用性問題: なし
Interoperability considerations: none
広められた仕様: このドキュメント
Published specification: This document
このメディアタイプを使用するアプリケーション: このドキュメントタイプは、会議アプリケーションをSIPにサポートするのに使用されました。
Applications which use this media type: This document type has been
used to support SIP conferencing applications
追加情報:
Additional Information:
マジックナンバー: なし
Magic Number: None
ファイル拡張子: .xml
File Extension: .xml
マッキントッシュファイルの種類コード: 「テキスト」
Macintosh file type code: "TEXT"
詳細のためのパーソナルとEメールアドレス: IETF SIPPING Working Group <sipping@ietf.org 、gt;、 IESG <iesg@ietf.org によって指定される、gt。
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
Rosenberg, et al. Standards Track [Page 42] RFC 4575 Conference Package August 2006
Author/Change controller: IETF SIPPING Working Group
<sipping@ietf.org>, as designated by the IESG <iesg@ietf.org>
9.3. つぼ:ietf:params:xml:ナノ秒間のURN Sub-名前空間Registration: 会議インフォメーション
9.3. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:conference-info
このセクションはRFC3688[21]のガイドラインに従って新しいXML名前空間を登録します。
This section registers a new XML namespace, as per the guidelines in RFC 3688 [21].
URI: この名前空間のためのURI、つぼ:ietf:params:xml:ナノ秒: 会議インフォメーションです。
URI: The URI for this namespace is
urn:ietf:params:xml:ns:conference-info
記入者接触: IETF SIPPING Working Group <sipping@ietf.org 、gt;、 IESG <iesg@ietf.org によって指定される、gt。
Registrant Contact: IETF SIPPING Working Group <sipping@ietf.org>,
as designated by the IESG <iesg@ietf.org>
XML:
XML:
BEGIN<?xmlバージョン= 「1インチ?」><!DOCTYPE html PUBLIC「-//W3C//DTD XHTML基礎1.0//アン」、「 http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd 、「><html xmlnsが「 http://www.w3.org/1999/xhtml 「><ヘッド><メタhttp-equiv=」content type」内容=と等しい、「テキスト/html;、charset=iso8859、1インチ、/><タイトル>コンファレンス情報名前空間</タイトル>、」
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>
コンファレンス情報</h1><h2>つぼ:ietf:params: xml:ナノ秒:会議インフォメーション</h2><p>See<a hrefのための</ヘッド<ボディー><h1>Namespaceが等しい、「 http://www.rfc-editor.org/rfc/rfc4575.txt 、「>RFC4575</a></p></ボディー></html>END」
</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
9.4. XML図式登録
9.4. XML Schema Registration
この仕様はRFC3688[21]のガイドラインに従って図式を登録します。
This specification registers a schema, as per the guidelines in RFC 3688 [21].
URI: 割り当ててください。
URI: please assign
記入者接触: IETF SIPPING Working Group <sipping@ietf.org 、gt;、 IESG <iesg@ietf.org によって指定される、gt。
Registrant Contact: IETF SIPPING Working Group <sipping@ietf.org>,
as designated by the IESG <iesg@ietf.org>
XML: セクション6の唯一の内容としてXMLを見つけることができます。
XML: The XML can be found as the sole content of Section 6.
Rosenberg, et al. Standards Track [Page 43] RFC 4575 Conference Package August 2006
9.5. URI Purposes Sub-registry Establishment
IANAは既に既存の登録の下で新しいサブ登録、「URI目的」を作成しました: http://www.iana.org/assignments/sip-parameters 。
The IANA has created a new sub-registry, "URI purposes", under the already existing registry: http://www.iana.org/assignments/sip-parameters.
URIの目的は会議イベントパッケージRFC4575の中にコード化されたXML要素です。 <目的>要素の価値は、会議イベントパッケージの文脈でURIの意図している用法を示して、セクション5.3.1で定義されます、そして、この.2の仕様が5.3が定義されます。
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.
このサブ登録は以下の3つのコラムを含むテーブルと定義されます:
This sub-registry is defined as a table that contains the following three columns:
値: 登録でのトークン
Value: The token under registration
記述: URIの意図している用法を定義する説明文
Description: A descriptive text defining the intended usage of the
URI
以下を記録してください。 登録を定義するドキュメントの参照
Document: A reference to the document defining the registration
IANAは以下で定義されるように初期の内容でテーブルを作成しました:
The IANA has created the table with the initial content as defined below:
値の記述ドキュメント------- ---------------------------------- ----------
Value Description Document ------- ---------------------------------- ----------
URIが使用されている場合がある参加は[RFC4575]会議に参加します。
participation The URI can be used to join the [RFC 4575]
conference
[RFC4575]流された会議データにアクセスするのにURIを流すのを使用できます。
streaming The URI can be used to access the [RFC 4575]
streamed conference data
URIが使用されている場合があるイベントは[RFC4575]を会議イベントパッケージに申し込みます。
event The URI can be used to subscribe [RFC 4575]
to the conference event package
[RFC4575]記録された会議データにアクセスするのにURIを記録するのを使用できます。
recording The URI can be used to access the [RFC 4575]
recorded conference data
URIが使用されている場合があるウェブページは会議に関する追加情報を含む[RFC4575]ウェブページにアクセスします。
web-page The URI can be used to access a [RFC 4575]
web page that contains additional
information of the conference
「URI目的」の新しい値は、IANAによって登録されて、RFC2434[4]の定義に従って必要である仕様です。 仕様のIANA Considerations部は以下の情報を含めなければなりません:
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:
Rosenberg, et al. Standards Track [Page 44] RFC 4575 Conference Package August 2006
Value: The value of the <purpose> element to be registered
記述: URIの意図している用法の短い記述
Description: A short description of the intended usage of the URI
10. 承認
10. Acknowledgements
作者は彼らのコメントと入力についてダン・ピートリー、ショーン・オルソン、アラン・ジョンストン、Rohanマーイ、Cullenジョニングス、ブライアン・ローゼン、ロニEven、およびミゲル・ガルシアに感謝したがっています。
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.
11. 参照
11. References
11.1. 引用規格
11.1. Normative References
[1] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2]堀(R.、「つぼの構文」、RFC2141)は1997がそうするかもしれません。
[2] Moats, R., "URN Syntax", RFC 2141, May 1997.
[3] ハンドレー、M.、ジェーコブソン、V.、およびC.パーキンス、「SDP:」 「セッション記述プロトコル」、RFC4566、2006年7月。
[3] Handley, M., Jacobson, V. and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[4]Narten、T.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
[4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October
1998.
[5] イーストレーク3番目とD.とA.パニツ、「予約された最高平らなDNS名」、BCP32、RFC2606、1999年6月。
[5] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS Names",
BCP 32, RFC 2606, June 1999.
[6] モウツ、R.、「IETFドキュメントのためのつぼの名前空間」、RFC2648、1999年8月。
[6] Moats, R., "A URN Namespace for IETF Documents", RFC 2648,
August 1999.
[7] ムラタとM.と聖ローラン、S.とD.コーン、「XMLメディアタイプ」、RFC3023、2001年1月。
[7] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types",
RFC 3023, January 2001.
[8] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
[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.
[9] ローゼンバーグとJ.とH.Schulzrinne、「セッション記述プロトコル(SDP)がある申し出/答えモデル」、RFC3264、2002年6月。
[9] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002.
[10] ローチ、A.B.、「セッション開始プロトコル(一口)特定のイベント通知」、RFC3265、2002年6月。
[10] Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
[11] ピーターソン、J.、「セッション開始プロトコル(一口)のためのプライバシーメカニズム」、RFC3323、2002年11月。
[11] Peterson, J., "A Privacy Mechanism for the Session Initiation
Protocol (SIP)", RFC 3323, November 2002.
Rosenberg, et al. Standards Track [Page 45] RFC 4575 Conference Package August 2006
[12] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason Header
Field for the Session Initiation Protocol (SIP)", RFC 3326,
December 2002.
[13]Schulzrinne、H.、Casner、S.、フレディリック、R.、およびV.ジェーコブソン、「RTP:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、STD64、RFC3550、2003年7月。
[13] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", STD 64,
RFC 3550, July 2003.
[14]Yergeau、F.、「UTF-8、ISO10646インチ、STD63、RFC3629、11月2003日の変換形式
[14] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD
63, RFC 3629, November 2003.
[15] スパークス、R.、「参照されたセッション開始プロトコル(一口)メカニズム」、RFC3892、2004年9月。
[15] Sparks, R., "The Session Initiation Protocol (SIP) Referred-By
Mechanism", RFC 3892, September 2004.
2006年2月の[16] ローゼンバーグ、J.、「セッション開始プロトコル(一口)がある会議のためのフレームワーク」RFC4353。
[16] Rosenberg, J., "A Framework for Conferencing with the Session
Initiation Protocol (SIP)", RFC 4353, February 2006.
[17] レヴィンとO.とG.キャマリロ、「セッション記述プロトコル(SDP)ラベル属性」、RFC4574、2006年8月。
[17] Levin, O. and G. Camarillo, "The Session Description Protocol
(SDP) Label Attribute", RFC 4574, August 2006.
11.2. 有益な参照
11.2. Informative References
1998年4月の[18]SchulzrinneとH.とラオ、A.とR.Lanphier、「リアルタイムのストリーミングのプロトコル(RTSP)」RFC2326。
[18] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming
Protocol (RTSP)", RFC 2326, April 1998.
[19]Schulzrinne、2004年12月のH.、「Telephone民数記のためのtel URI」RFC3966。
[19] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966,
December 2004.
[20] レヴィン、O.、「H.323Uniform Resource Locator(URL)体系登録」、RFC3508、2003年4月。
[20] Levin, O., "H.323 Uniform Resource Locator (URL) Scheme
Registration", RFC 3508, April 2003.
[21] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004.
[21] 食事、M.、「IETF XML登録」、BCP81、RFC3688、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] サンアンドレ、P.、「広げることができるメッセージングと存在プロトコル(XMPP)のUniform Resource Identifier(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] ローゼンバーグ、J.、Schulzrinne、H.、およびR.マーイ、「招待はセッション開始プロトコル(一口)のために対話イベントパッケージを開始しました」、RFC4235、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] ローゼンバーグ、J.、「セッション開始プロトコル(一口)にRoutableユーザエージェント(UA)URI(GRUU)をグローバルに得て、使用すること」は進行中(2006年5月)で働いています。
Rosenberg, et al. Standards Track [Page 46] RFC 4575 Conference Package August 2006
ローゼンバーグ、他 規格はコンファレンスパッケージ2006年8月にRFC4575を追跡します[46ページ]。
[25] Peterson, J. and C. Jennings, "Enhancements for Authenticated
Identity Management in the Session Initiation Protocol (SIP)",
RFC 4474, August 2006.
[25] ピーターソン、J.、およびC.ジョニングス、「セッション開始における認証されたアイデンティティ管理のための増進は(一口)について議定書の中で述べます」、RFC4474、2006年8月。
Authors' Addresses
作者のアドレス
Jonathan Rosenberg Cisco Systems 600 Lanidex Plaza Parsippany, NJ 07054 US
ジョナサンローゼンバーグシスコシステムズ600Lanidex Plazaニュージャージー07054パーシッパニー(米国)
Phone: +1 973 952-5000 EMail: jdrosen@cisco.com URI: http://www.jdrosen.net
以下に電話をしてください。 +1 973 952-5000 メールしてください: jdrosen@cisco.com ユリ: http://www.jdrosen.net
Henning Schulzrinne Columbia University M/S 0401 1214 Amsterdam Ave. New York, NY 10027 US
ヘニングSchulzrinneコロンビア大学M/S0401 1214アムステルダムAve。 ニューヨーク、ニューヨーク10027米国
EMail: schulzrinne@cs.columbia.edu URI: http://www.cs.columbia.edu/~hgs
メール: schulzrinne@cs.columbia.edu ユリ: http://www.cs.columbia.edu/~hgs
Orit Levin (editor) Microsoft Corporation One Microsoft Way Redmond, WA 98052 US
Oritレヴィン、(エディタ)マイクロソフト社1マイクロソフト道のワシントン98052レッドモンド(米国)
EMail: oritl@microsoft.com
メール: oritl@microsoft.com
Rosenberg, et al. Standards Track [Page 47] RFC 4575 Conference Package August 2006
ローゼンバーグ、他 規格はコンファレンスパッケージ2006年8月にRFC4575を追跡します[47ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Rosenberg, et al. Standards Track [Page 48]
ローゼンバーグ、他 標準化過程[48ページ]
一覧
スポンサーリンク
