Network Working Group G. Camarillo
Request for Comments: 5366 Ericsson
Category: Standards Track A. Johnston
Avaya
October 2008
Conference Establishment Using Request-Contained Lists
in the Session Initiation Protocol (SIP)
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Abstract
抽象
This document describes how to create a conference using SIP URI-list services. In particular, it describes a mechanism that allows a User Agent Client to provide a conference server with the initial list of participants using an INVITE-contained URI list.
この文書では、SIP URI - リストサービスを使用して会議を作成する方法について説明します。特に、ユーザエージェントクライアントがINVITE-含まれるURIのリストを使用して、参加者の初期リストとの会議サーバを提供することを可能にするメカニズムを説明しています。
Table of Contents
目次
1. Introduction ....................................................2
2. Terminology .....................................................2
3. User Agent Client Procedures ....................................2
3.1. Response Handling ..........................................2
3.2. Re-INVITE Request Generation ...............................3
4. URI-List Document Format ........................................3
5. Conference Server Procedures ....................................5
5.1. Re-INVITE Request Handling .................................6
6. Example .........................................................6
7. Security Considerations ........................................10
8. IANA Considerations ............................................10
9. Acknowledgments ................................................11
10. References ....................................................11
10.1. Normative References .....................................11
10.2. Informative References ...................................12
Section 5.4 of [RFC4579] describes how to create a conference using ad hoc SIP [RFC3261] methods. The client sends an INVITE request to a conference factory URI and receives the actual conference URI, which contains the "isfocus" feature tag, in the Contact header field of a response -- typically a 200 (OK) response.
[RFC4579]のセクション5.4は、アドホックSIP [RFC3261]方法を使用して会議を作成する方法について説明します。クライアントは、会議工場のURIにINVITEリクエストを送信し、応答のContactヘッダーフィールドでは、「isfocus」フィーチャータグが含まれている実際の会議URI、受信 - 通常は200（OK）応答を。
Once the UAC (User Agent Client) obtains the conference URI, it can add participants to the newly created conference in several ways, which are described in [RFC4579].
UAC（ユーザエージェントクライアント）が会議URIを取得したら、それは[RFC4579]で説明されているいくつかの方法で、新しく作成された会議に参加者を追加することができます。
Some environments have tough requirements regarding conference establishment time. They require the UAC to be able to request the creation of an ad hoc conference and to provide the conference server with the initial set of participants in a single operation. This document describes how to meet this requirement using the mechanism to transport URI lists in SIP messages described in [RFC5363].
一部の環境では、会議の設立時間に関する厳しい要件があります。彼らは、アドホック会議の作成を要求できるようにすると、単一の操作で、参加者の初期セットで会議サーバを提供するために、UACが必要です。この文書では、[RFC5363]で説明したSIPメッセージでURIリストを輸送するためのメカニズムを使用して、この要件を満たす方法について説明します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
A UAC that wants to include the set of initial participants in its initial INVITE request to create an ad hoc conference adds a body whose disposition type is 'recipient-list', as defined in [RFC5363], with a URI list that contains the participants that the UAC wants the conference server to invite. Additionally, the UAC MUST include the 'recipient-list-invite' option-tag (which is registered with the IANA in Section 8) in a Require header field. The UAC sends this INVITE request to the conference factory URI.
アドホック会議を作成するには、その最初のINVITE要求における最初の参加者の集合を含めたいUACは、その気質タイプの参加者が含まれているURIのリストで、[RFC5363]で定義されているように、「受信者リスト」で体を追加しますUACは、招待する会議サーバを望んでいます。また、UACはRequireヘッダーフィールドに（セクション8にIANAに登録されている）、「受信者リスト招待」オプションタグを含まなければなりません。 UACは、会議工場のURIにこのINVITEリクエストを送信します。
The INVITE transaction is also part of an offer/answer exchange that will establish a session between the UAC and the conference server, as specified in [RFC4579]. Therefore, the INVITE request may need to carry a multipart body: a session description and a URI list.
INVITEトランザクションも[RFC4579]で指定されるように、UACと会議サーバ間のセッションを確立しますオファー/アンサー交換の一部です。セッション記述とURIリスト：したがって、INVITEリクエストがマルチパートボディを運ぶために必要があるかもしれません。
The status code in the response to the INVITE request does not provide any information about whether or not the conference server was able to bring the users in the URI list into the conference. That is, a 200 (OK) response means that the conference was created successfully, that the UAC that generated the INVITE request is in the conference, and that the server understood the URI list. If the UAC wishes to obtain information about the status of other users in the conference, it SHOULD use general conference mechanisms, such as the conference package, which is defined in [RFC4575].
INVITE要求に応じてステータスコードは、会議サーバが会議にURIリスト内のユーザーを持って来ることができたかどうかについての情報を提供していません。これは、200（OK）応答は、INVITEリクエストを生成UACが会議であり、サーバはURIのリストを理解することをことを、会議の作成に成功したことを意味しています。 UACは、会議における他のユーザのステータスに関する情報を取得したい場合、このような[RFC4575]で定義されている会議パッケージとして一般的な会議メカニズムを使用する必要があります。
The previous sections have specified how to include a URI list in an initial INVITE request to a conference server. Once the INVITE-initiated dialog between the UAC and the conference server has been established, the UAC can send subsequent INVITE requests (typically referred to as re-INVITE requests) to the conference server to, for example, modify the characteristics of the media exchanged with the server.
前のセクションでは、会議サーバに最初のINVITE要求にURIのリストを含める方法を指定しています。 UACと会議サーバとの間のINVITEが開始ダイアログが確立されると、UACは、例えば、媒体の特性を変更するために会議サーバに後続のINVITE要求（典型的には、再INVITE要求と呼ぶ）を送信することができる交換サーバと。
At this point, there are no semantics associated with 'recipient-list' bodies in re-INVITE requests (although future extensions may define them). Therefore, UACs SHOULD NOT include 'recipient-list' bodies in re-INVITE requests sent to a conference server.
この時点で、再INVITEリクエスト（将来の拡張は、それらを定義するかもしれないが）に「受信者リストの体に関連した意味はありません。したがって、求めるUACは、会議サーバに送信された再INVITEリクエストで「受信者リストの体を含めるべきではありません。
Note that a difference between an initial INVITE request and a re-INVITE request is that while the initial INVITE request is sent to the conference factory URI, the re-INVITE request is sent to the URI provided by the server in a Contact header field when the dialog was established. Therefore, from the UAC's point of view, the resource identified by the former URI supports 'recipient-list' bodies, while the resource identified by the latter does not support them.
初期INVITE要求と再INVITE要求は初期INVITE要求が会議ファクトリーURIに送信されている間、再INVITE要求がURIに送信されることであるContactヘッダーフィールド内のサーバによって提供されるとの間の違いに注意してくださいダイアログが設立されました。後者で識別されるリソースは、それらをサポートしていませんがため、ビューのUACの視点から、旧URIで識別されるリソースは、「受信者リストの体をサポートしています。
As described in [RFC5363], specifications of individual URI-list services, like the conferencing service described here, need to specify a default format for 'recipient-list' bodies used within the particular service.
[RFC5363]で説明したように、個々のURIリストサービスの仕様は、ここで説明する会議サービスのように、特定のサービス内で使用される「受信者リストの体のデフォルト形式を指定する必要があります。
The default format for 'recipient-list' bodies for conferencing UAs (User Agents) is the XML resource list format (which is specified in [RFC4826]) extended with the "Extensible Markup Language (XML) Format Extension for Representing Copy Control Attributes in Resource Lists" [RFC5364]. Consequently, conferencing UACs generating 'recipient-list' bodies MUST support both of these formats and MAY support other formats. Conferencing servers able to handle 'recipient-list' bodies MUST support both of these formats and MAY support other formats.
会議のUA（ユーザーエージェント）のための「受信者リストの体のデフォルトの形式は、コピー制御を表現するための「拡張マークアップ言語（XML）フォーマットの拡張で拡張（[RFC4826]で指定された）XMLリソースリスト形式は、の属性れますリソースリスト」[RFC5364]。その結果、「受信者リストの体を生成する会議求めるUACは、これらのフォーマットの両方をサポートしなければならないし、他のフォーマットをサポートするかもしれません。 「受信者リストの体を処理することができる会議サーバは、これらのフォーマットの両方をサポートしなければならないし、他のフォーマットをサポートするかもしれません。
As described in "Extensible Markup Language (XML) Format Extension for Representing Copy Control Attributes in Resource Lists" [RFC5364], each URI can be tagged with a 'copyControl' attribute set
[RFC5364]を「コピー制御は、リソースリスト内の属性表現するための拡張マークアップ言語（XML）フォーマットの拡張」で説明したように、各URIは、「コピーコントロールCD」属性セットでタグ付けすることができます
to either "to", "cc", or "bcc", indicating the role in which the recipient will get the INVITE request. Additionally, URIs can be tagged with the 'anonymize' attribute to prevent the conference server from disclosing the target URI in a URI list.
いずれかの受信者がINVITEリクエストを取得しますれる役割を示し、「CC」、または「BCC」、「へ」。また、URIはURIリストにターゲットURIを開示から会議サーバを防ぐために「匿名化」属性でタグ付けすることができます。
In addition, "Extensible Markup Language (XML) Format Extension for Representing Copy Control Attributes in Resource Lists" [RFC5364] defines a 'recipient-list-history' body that contains the list of recipients. The default format for 'recipient-list-history' bodies for conferencing UAs is also the XML resource list document format specified in [RFC4826] extended with "Extensible Markup Language (XML) Format Extension for Representing Copy Control Attributes in Resource Lists" [RFC5364]. Consequently, conferencing UACs able to generate 'recipient-list-history' bodies MUST support these formats and MAY support others. Conferencing UAs able to understand 'recipient-list-history' MUST support these formats and MAY support others. Conferencing servers able to handle 'recipient-list-history' bodies MUST support these formats and MAY support others.
また、「コピー制御を表現するための拡張マークアップ言語（XML）形式拡張子は、リソースリストに属性」[RFC5364]は、受信者のリストが含まれている「受信者リスト履歴の体を定義します。会議のUAのための「受信者リスト履歴の体のデフォルトのフォーマットでもあると、拡張で指定されたXMLリソースリスト文書形式[RFC4826]「コピーコントロールを表すための拡張マークアップ言語（XML）形式拡張子は、リソースリストに属性」[RFC5364 ]。その結果、これらのフォーマットをサポートしなければならない "受信者リスト履歴の体を生成することができ求めるUACを会議や他の人をサポートするかもしれません。 「受信者リスト履歴」を理解することができ会議UAは、これらのフォーマットをサポートしなければならないし、他の人をサポートするかもしれません。 「受信者リスト履歴の体を処理することができる会議サーバは、これらのフォーマットをサポートしなければならないし、他の人をサポートするかもしれません。
Nevertheless, the XML resource list document specified in [RFC4826] provides features, such as hierarchical lists and the ability to include entries by reference relative to the XML Configuration Access Protocol (XCAP) root URI, that are not needed by the conferencing service defined in this document, which only needs to transfer a flat list of URIs between a UA (User Agent) and the conference server. Therefore, when using the default resource list document, conferencing UAs SHOULD use flat lists (i.e., no hierarchical lists) and SHOULD NOT use <entry-ref> elements. A conference factory application receiving a URI list with more information than what has just been described MAY discard all the extra information.
それにもかかわらず、[RFC4826]で指定されたXMLリソースリスト文書は、このような階層リストとで定義された会議サービスによって必要とされていないXMLコンフィギュレーションアクセスプロトコル（XCAP）ルートURIを参照の相対でエントリを含める機能などの機能を提供し、唯一のUA（ユーザーエージェント）と会議サーバ間のURIのフラットリストを転送する必要があり、この文書、。したがって、デフォルトのリソース・リスト・ドキュメントを使用した場合、会議UAはフラットリスト（すなわち、無階層リスト）を使用すべきであるとの<entry-ref>を要素を使用しないでください。今説明されたものよりも多くの情報をURIのリストを受信会議工場のアプリケーションは、すべての余分な情報を捨てるかもしれ。
Figure 1 shows an example of a flat list that follows the XML resource list document (specified in [RFC4826]) extended with "Extensible Markup Language (XML) Format Extension for Representing Copy Control Attributes in Resource Lists" [RFC5364].
図1は、[RFC5364]「リソースリストの属性コピー制御を表すための拡張マークアップ言語（XML）フォーマットの拡張子」で拡張（[RFC4826]で指定された）XMLリソースリスト文書を以下のフラットリストの一例を示しています。
<?xml version="1.0" encoding="UTF-8"?> <resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists" xmlns:cp="urn:ietf:params:xml:ns:copycontrol"> <list> <entry uri="sip:bill@example.com" cp:copyControl="to" /> <entry uri="sip:joe@example.org" cp:copyControl="cc" /> <entry uri="sip:ted@example.net" cp:copyControl="bcc" /> </list> </resource-lists>
<？xml version = "1.0" エンコード= "UTF-8"？> <リソース・リストののxmlns = "壷：IETF：のparams：XML：NS：リソース・リスト" のxmlns：CP = "壷：IETF：のparams：XML ：NS：コピーコントロールCD "> <リスト> <エントリーのURI =" SIP：bill@example.com "CP：コピーコントロールCD = "へ"/> <エントリURI = "SIP：joe@example.org" CP：コピーコントロールCD =" CC "/> <エントリURI =" SIP：ted@example.net」CP：コピーコントロールCD = "BCC" /> </リスト> </資源リスト>
Figure 1: URI list
図1：URIリスト
Conference servers that are able to receive and process INVITE requests with a 'recipient-list' body SHOULD include a 'recipient-list-invite' option-tag in a Supported header field when responding to OPTIONS requests.
OPTIONS要求に応答する際に受信して処理することができます会議サーバーは、サポートされているヘッダフィールド内の「受信者リスト - 招待」オプションタグを含むべきである「受信者リストの体を持つINVITE要求。
On reception of an INVITE request containing a 'recipient-list' body as described in Section 3, a conference server MUST follow the rules described in [RFC4579] to create ad hoc conferences. Once the ad hoc conference is created, the conference server SHOULD attempt to add the participants in the URI list to the conference as if their addition had been requested using any of the methods described in [RFC4579].
セクション3に記載されているように「受信者リスト」本体を含むINVITE要求を受信すると、会議サーバは、アドホック会議を作成するために、[RFC4579]に記載の規則に従わなければなりません。アドホック会議が作成されたら、会議サーバは、それらの添加は、[RFC4579]に記載された方法のいずれかを使用して、要求されたかのように会議にURIリストに参加者を追加しようとすべきです。
The INVITE transaction is also part of an offer/answer exchange that will establish a session between the UAC and the conference server, as specified in [RFC4579]. Therefore, the INVITE request may carry a multipart body: a session description and a URI list.
INVITEトランザクションも[RFC4579]で指定されるように、UACと会議サーバ間のセッションを確立しますオファー/アンサー交換の一部です。セッション記述とURIリスト：したがって、INVITEリクエストがマルチパートボディを搬送することができます。
Once the conference server has created the ad hoc conference and has attempted to add the initial set of participants, the conference server behaves as a regular conference server and MUST follow the rules in [RFC4579].
会議サーバは、アドホック会議を作成したと参加者の初期セットを追加しようとしたら、会議サーバは、定期的な会議サーバとして動作して、[RFC4579]の規則に従わなければなりません。
The incoming INVITE request will contain a URI-list body or reference (as specified in [RFC5363]) with the actual list of recipients. If this URI list includes resources tagged with the 'copyControl' attribute set to a value of "to" or "cc", the conference server SHOULD include a URI list in each of the outgoing INVITE requests. This list SHOULD be formatted according to the XML format for representing resource lists (specified in [RFC4826]) and the copyControl extension specified in [RFC5364].
着信INVITE要求は、受信者の実際のリストを（[RFC5363]で指定されるように）URIリスト体又は参照を含むことになります。このURIのリストは、「へ」または「CC」の値に設定する「コピーコントロールCD」属性でタグ付けされたリソースが含まれている場合は、会議サーバは、発信INVITEリクエストのそれぞれにおけるURIのリストを含むべきです。このリストは、リソースリストを表現するためのXMLフォーマット（[RFC4826]で指定）および[RFC5364]で指定されたコピーコントロールCDの拡張に応じてフォーマットされるべきです。
The URI-list service MUST follow the procedures specified in [RFC5364] with respect to the handling of the 'anonymize', 'count', and 'copyControl' attributes.
URIリストサービスは、「匿名化」、「数」、および「コピーコントロールCDの属性の取り扱いに関して[RFC5364]で指定された手順に従わなければなりません。
If the conference server includes a URI list in an outgoing INVITE request, it MUST include a Content-Disposition header field (which is specified in [RFC2183]) with the value set to 'recipient-list-history' and a 'handling' parameter (as specified in [RFC3204]) set to "optional".
会議サーバは、発信INVITE要求におけるURIのリストが含まれている場合、それは、受信者リスト履歴」および「処理」パラメータの設定値と（[RFC2183]で指定されている）のContent-Dispositionヘッダーフィールドを含まなければなりません（[RFC3204]で指定されるように）「オプション」に設定されます。
At this point, there are no semantics associated with 'recipient-list' bodies in re-INVITE requests (although future extensions may define them). Therefore, a conference server receiving a re-INVITE request with a 'recipient-list' body and, consequently, a 'recipient-list-invite' option-tag, following standard SIP procedures, rejects it with a 420 (Bad Extension), which carries an Unsupported header field listing the 'recipient-list-invite' option-tag.
この時点で、再INVITEリクエスト（将来の拡張は、それらを定義するかもしれないが）に「受信者リストの体に関連した意味はありません。したがって、標準的なSIPの手順に従って、「受信者リスト」体で要求を再招待し、その結果、「受信者リスト招待」オプションタグを受信する会議サーバは、420（悪い拡張）でそれを拒否し、これは「受信者リスト - 招待」オプションタグをリストサポートされていないヘッダフィールドを運びます。
This is because the resource identified by the conference URI does not actually support this extension. On the other hand, the resource identified by the conference factory URI does support this extension and, consequently, would include the 'recipient-list-invite' option-tag in, for example, responses to OPTIONS requests.
会議URIで識別されるリソースが実際にこの拡張機能をサポートしていないためです。一方、会議工場のURIで識別されるリソースは、結果的に、の「受信者リスト - 招待」オプションタグ、OPTIONS要求に例えば、応答が含まれるであろう、この拡張機能をサポートします。
Figure 2 shows an example of operation. A UAC sends an INVITE request (F1) that contains an SDP body and a URI list to the conference server. The conference server answers with a 200 (OK) response and generates an INVITE request to each of the UASs (User Agent Servers) identified by the URIs included in the URI list. The conference server includes SDP and a manipulated URI list in each of the outgoing INVITE requests.
図2は、動作の一例を示しています。 UACは、会議サーバにSDP本体とURIのリストが含まれているINVITEリクエスト（F1）を送信します。 URIで識別される会議サーバ200（OK）応答で答えとのUAS（ユーザエージェントサーバ）のそれぞれに、INVITE要求を生成は、URIのリストに含まれています。会議サーバは、SDPおよび発信INVITEリクエストのそれぞれにおける操作URIのリストが含まれています。
+--------+ +---------+ +--------+ +--------+ +--------+
|SIP UAC | | confer. | |SIP UAS | |SIP UAS | |SIP UAS |
| | | server | | 1 | | 2 | | n |
+--------+ +---------+ +--------+ +--------+ +--------+
| | | | |
| F1 INVITE | | | |
| ---------------->| | | |
| F2 200 OK | | | |
|<---------------- | F3 INVITE | | |
| | ------------->| | |
| | F4 INVITE | | |
| | ------------------------>| |
| | F5 INVITE | | |
| | ----------------------------------->|
| | F6 200 OK | | |
| |<------------- | | |
| | F7 200 OK | | |
| |<------------------------ | |
| | F8 200 OK | | |
| |<----------------------------------- |
| | | | |
| | | | |
| | | | |
Figure 2: Example of operation
図2の動作例
Figure 3 shows an example of the INVITE request F1, which carries a multipart/mixed body composed of two other bodies: an application/sdp body that describes the session and an application/resource-lists+xml body that contains the list of target URIs.
図3は、2人の他の体の混合/マルチボディを運び、INVITEリクエストF1の一例を示している：ターゲットURIのリストを含むアプリケーション/セッションを記述するSDP本体とアプリケーション/リソースリスト+ XML本体。
INVITE sip:conf-fact@example.com SIP/2.0 Via: SIP/2.0/TCP atlanta.example.com ;branch=z9hG4bKhjhs8ass83 Max-Forwards: 70 To: "Conf Factory" <sip:conf-fact@example.com> From: Alice <sip:alice@example.com>;tag=32331 Call-ID: d432fa84b4c76e66710 CSeq: 1 INVITE Contact: <sip:alice@atlanta.example.com> Allow: INVITE, ACK, CANCEL, BYE, REFER Allow-Events: dialog Accept: application/sdp, message/sipfrag Require: recipient-list-invite Content-Type: multipart/mixed;boundary="boundary1" Content-Length: 690
ブランチ= z9hG4bKhjhs8ass83マックス・転送し、SIP / 2.0 / TCP atlanta.example.com：70： "コンファレンスファクトリー" <一口：conf-fact@example.com conf-fact@example.com SIP / 2.0経由：SIPのINVITE >投稿者：アリス<SIP：alice@example.com>;タグは= 32331コールID：d432fa84b4c76e66710ののCSeq：1連絡先をINVITE：<SIP：alice@atlanta.example.com>許可：REFER、BYE、CANCEL、ACKをINVITE許可 - イベント：ダイアログが受け入れ：アプリケーション/ SDPを、メッセージ/ sipfragを要求：受信者リスト - 招待のContent-Typeを：混合/マルチパート;境界= "boundary1" のContent-Length：690
--boundary1 Content-Type: application/sdp
--boundary1のContent-Type：アプリケーション/ SDP
v=0 o=alice 2890844526 2890842807 IN IP4 atlanta.example.com s=- c=IN IP4 192.0.2.1 t=0 0 m=audio 20000 RTP/AVP 0 a=rtpmap:0 PCMU/8000 m=video 20002 RTP/AVP 31 a=rtpmap:31 H261/90000
V = 0 0 =アリス2890844526 2890842807 IN IP4 atlanta.example.com S = - C = IN IP4 192.0.2.1 T = 0、M =オーディオ20000 RTP / AVP 0 A = rtpmap：0 PCMU / 8000メートル=ビデオ20002 RTP / AVP 31 = rtpmap：31 H261 / 90000
--boundary1 Content-Type: application/resource-lists+xml Content-Disposition: recipient-list
--boundary1のContent-Type：アプリケーション/リソース・リスト+ xmlのコンテンツディスポジション：受信者リスト
<?xml version="1.0" encoding="UTF-8"?> <resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists" xmlns:cp="urn:ietf:params:xml:ns:copyControl"> <list> <entry uri="sip:bill@example.com" cp:copyControl="to" /> <entry uri="sip:randy@example.net" cp:copyControl="to" cp:anonymize="true"/> <entry uri="sip:eddy@example.com" cp:copyControl="to" cp:anonymize="true"/> <entry uri="sip:joe@example.org" cp:copyControl="cc" /> <entry uri="sip:carol@example.net" cp:copyControl="cc" cp:anonymize="true"/> <entry uri="sip:ted@example.net" cp:copyControl="bcc" /> <entry uri="sip:andy@example.com" cp:copyControl="bcc" /> </list> </resource-lists> --boundary1--
<？xml version = "1.0" エンコード= "UTF-8"？> <リソース・リストののxmlns = "壷：IETF：のparams：XML：NS：リソース・リスト" のxmlns：CP = "壷：IETF：のparams：XML ：NS：コピーコントロールCD "> <リスト> <エントリーのURI =" SIP：bill@example.com "CP：コピーコントロールCD = "へ"/> <エントリーのURI = "SIP：randy@example.net" CP：コピーコントロールCD =" へ"CP：匿名=" 真 "/> <エントリURI =" SIP：eddy@example.com "CP：コピーコントロールCD = "と" CP：匿名= "真"/> <エントリURI =" 一口例：@ジョー。 ORG "CP：コピーコントロールCD = "CC"/> <エントリURI = "SIP：carol@example.net" CP：コピーコントロールCD = "CC" CP：匿名= "真"/> <エントリURI =" 一口：テッド例@ .NETの」CP：コピーコントロールCD = "BCC" /> <エントリURI = "SIP：andy@example.com" CP：コピーコントロールCD = "BCC" /> </リスト> </リソース・リスト> --boundary1--
Figure 3: INVITE request received at the conference server
図3：INVITE要求は、会議サーバで受信しました
The INVITE requests F3, F4, and F5 are similar in nature. All those INVITE requests contain a multipart/mixed body that is composed of two other bodies: an application/sdp body describing the session and an application/resource-lists+xml containing the list of recipients. The application/resource-lists+xml bodies are not equal to the application/resource-lists+xml included in the received INVITE request F1, because the conference server has anonymized those URIs tagged with the 'anonymize' attribute and has removed those URIs tagged with a "bcc" 'copyControl' attribute. Figure 4 shows an example of the message F3.
INVITEリクエストF3、F4、F5とは本質的に似ています。アプリケーション/セッションを記述するSDPボディと受信者のリストを含むアプリケーション/リソース・リスト+ xmlの：すべてのこれらの要求は他の二つの団体で構成されているmultipart / mixedの体を含んでINVITE。アプリケーション/リソースリスト+ XML本体は+ XMLアプリケーション/リソース・リストに等しくない会議サーバは、それらのURIを匿名化しているため、受信したINVITEリクエストF1に含まれる「匿名」属性でタグ付けし、タグ付けされたそれらのURIを除去しました「BCC」「コピーコントロールCD」属性を持ちます。図4は、メッセージF3の例を示しています。
INVITE sip:bill@example.com SIP/2.0 Via: SIP/2.0/TCP conference.example.com ;branch=z9hG4bKhjhs8as454 Max-Forwards: 70 To: <sip:bill@example.com> From: Conference Server <sip:conf34@example.com>;tag=234332 Call-ID: 389sn189dasdf CSeq: 1 INVITE Contact: <sip:conf34@conference.example.com>;isfocus Allow: INVITE, ACK, CANCEL, BYE, REFER Allow-Events: dialog, conference Accept: application/sdp, message/sipfrag Content-Type: multipart/mixed;boundary="boundary1" Content-Length: 690
bill@example.com SIP / 2.0経由：SIPのINVITE SIP / 2.0 / TCP conference.example.com;ブランチ= z9hG4bKhjhs8as454マックス・フォワード：70：<SIP：bill@example.com>から：会議サーバ<SIP： conf34@example.com>;タグは= 234332コールID：のCSeq 389sn189dasdf：<SIP：1連絡先INVITE conf34@conference.example.comを>; isfocus許可：許可 - イベントをREFER、BYE、CANCEL、ACKをINVITE：ダイアログ、会議受け入れ：アプリケーション/ SDP、メッセージ/ sipfragのコンテンツタイプを：混合/マルチパート;境界= "boundary1" のContent-Lengthを：690
--boundary1 Content-Type: application/sdp
--boundary1のContent-Type：アプリケーション/ SDP
v=0 o=conf 2890844343 2890844343 IN IP4 conference.example.com s=- c=IN IP4 192.0.2.5 t=0 0 m=audio 40000 RTP/AVP 0 a=rtpmap:0 PCMU/8000 m=video 40002 RTP/AVP 31 a=rtpmap:31 H261/90000
V = 0 0 = CONF 2890844343 2890844343 IN IP4 conference.example.com S = - C = IN IP4 192.0.2.5 T = 0、M =オーディオ40000 RTP / AVP 0 A = rtpmap：0 PCMU / 8000メートル=ビデオ40002 RTP / AVP 31 = rtpmap：31 H261 / 90000
--boundary1 Content-Type: application/resource-lists+xml Content-Disposition: recipient-list-history; handling=optional
--boundary1のContent-Type：アプリケーション/リソース・リスト+ xmlのコンテンツディスポジション：受信者リスト履歴;取り扱い=オプション
<?xml version="1.0" encoding="UTF-8"?> <resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists" xmlns:cp="urn:ietf:params:xml:ns:copycontrol"> <list> <entry uri="sip:bill@example.com" cp:copyControl="to" /> <entry uri="sip:anonymous@anonymous.invalid" cp:copyControl="to" cp:count="2"/> <entry uri="sip:joe@example.org" cp:copyControl="cc" /> <entry uri="sip:anonymous@anonymous.invalid" cp:copyControl="cc" cp:count="1"/> </list> </resource-lists> --boundary1--
<？xml version = "1.0" エンコード= "UTF-8"？> <リソース・リストののxmlns = "壷：IETF：のparams：XML：NS：リソース・リスト" のxmlns：CP = "壷：IETF：のparams：XML ：NS：コピーコントロールCD "> <リスト> <エントリーのURI =" SIP：bill@example.com "CP：コピーコントロールCD = "へ：anonymous@anonymous.invalid "コピーコントロールCD = CP""/> <エントリのURIは=" 一口に"CP：カウント=" 2 "/> <エントリURI =" SIP：joe@example.org "CP：コピーコントロールCD = "CC"/> <エントリのURIは= "SIP：anonymous@anonymous.invalid" CP：コピーコントロールCD =" ccの」CP：カウント= "1" /> </リスト> </リソース・リスト> --boundary1--
Figure 4: INVITE request sent by the conference server
図4：会議サーバによって送信されたINVITEリクエスト
This document discusses setup of SIP conferences using a request-contained URI list. Both conferencing and URI-list services have specific security requirements, which are summarized here. Conferences generally have authorization rules about who can or cannot join a conference, what type of media can or cannot be used, etc. This information is used by the focus to admit or deny participation in a conference. It is RECOMMENDED that these types of authorization rules be used to provide security for a SIP conference.
この文書では、要求に含まれるURIのリストを使用してSIP会議のセットアップについて説明します。どちらの会議やURIリストサービスはここに要約されている特定のセキュリティ要件を、持っています。会議は、一般的または是認や会議への参加を拒否するために、焦点で使用されるなど、この情報または使用することはできません可能なメディアの種類会議に、参加できないことができる人についての認可規則を持っています。認可規則のこれらのタイプは、SIP会議のためのセキュリティを提供するために使用することをお勧めします。
For this authorization information to be used, the focus needs to be able to authenticate potential participants. Normal SIP mechanisms, including Digest authentication and certificates, can be used. These conference-specific security requirements are discussed further in the requirements and framework documents -- [RFC4245] and [RFC4353].
この認証情報が使用されるためには、焦点は、潜在的な参加者を認証できるようにする必要があります。ダイジェスト認証と証明書を含む、通常のSIPメカニズムを使用することができます。 [RFC4245]と[RFC4353] - これらの会議に固有のセキュリティ要件は、要件とフレームワーク文書で詳しく説明されています。
For conference creation using a list, there are some additional security considerations. "Framework and Security Considerations for Session Initiation Protocol (SIP) URI-List Services" [RFC5363] discusses issues related to SIP URI-list services. Given that a conference server sending INVITE requests to a set of users acts as a URI-list service, implementations of conference servers that handle lists MUST follow the security-related rules in [RFC5363]. These rules include opt-in lists and mandatory authentication and authorization of clients.
リストを使用して会議を作成するために、いくつかの追加のセキュリティの考慮事項があります。 [RFC5363]「セッション開始プロトコル（SIP）URIリストサービスのためのフレームワークとセキュリティの考慮事項は、」URIリストサービスをSIPに関連する問題について説明します。一連のユーザーにINVITE要求を送信する会議サーバはURIリストサービスとして動作していることを考えると、リストを扱う会議サーバの実装は、[RFC5363]でセキュリティ関連の規則に従わなければなりません。これらのルールは、オプトインリストと必須の認証とクライアントの承認が含まれています。
This document defines the 'recipient-list-invite' SIP option-tag. It has been registered in the Option Tags subregistry under the SIP parameter registry. The following is the description used in the registration:
この文書では、「受信者リスト - 招待」SIPオプションタグを定義します。これは、SIPパラメータレジストリの下にオプションタグ副登録に登録されています。以下は、登録に使用される説明です：
+------------------------+------------------------------+-----------+
| Name | Description | Reference |
+------------------------+------------------------------+-----------+
| recipient-list-invite | The body contains a list of | [RFC5366] |
| | URIs that indicates the | |
| | recipients of the SIP INVITE | |
| | request | |
+------------------------+------------------------------+-----------+
Table 1: Registration of the 'recipient-list-invite' option-tag in SIP
表1：SIPの「受信者リスト - 招待」オプションタグの登録
Cullen Jennings, Hisham Khartabil, Jonathan Rosenberg, and Keith Drage provided useful comments on this document. Miguel Garcia-Martin assembled the dependencies to the 'copyControl' attribute extension.
カレンジェニングス、ヒシャムKhartabil、ジョナサン・ローゼンバーグ、そしてキース糖剤はこのドキュメントの役に立つコメントを提供しました。ミゲル・ガルシア・マーティンは「コピーコントロールCD」属性の拡張機能に依存関係を組み立てました。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2183] Troost, R., Dorner, S., and K. Moore, Ed., "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", RFC 2183, August 1997.
[RFC2183] Troost、R.、ドルナー、S.、およびK.ムーア、エド、 "インターネット・メッセージでプレゼンテーション情報を伝える：コンテンツ-Dispositionヘッダーフィールド"。、RFC 2183、1997年8月。
[RFC3204] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, F., Watson, M., and M. Zonoun, "MIME media types for ISUP and QSIG Objects", RFC 3204, December 2001.
[RFC3204] Zimmerer、E.、ピーターソン、J.、Vemuri、A.、オング、L.、Audet、F.、ワトソン、M.、およびM. Zonoun、 "ISUPとQSIGオブジェクトのMIMEメディアタイプ"、RFC 3204、2001年12月。
[RFC3261] 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.
[RFC3261]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol (SIP) Call Control - Conferencing for User Agents", BCP 119, RFC 4579, August 2006.
[RFC4579]ジョンストン、A.、およびO.レヴィン、 "セッション開始プロトコル（SIP）呼制御 - ユーザエージェントのための会議"、BCP 119、RFC 4579、2006年8月。
[RFC4826] Rosenberg, J., "Extensible Markup Language (XML) Formats for Representing Resource Lists", RFC 4826, May 2007.
[RFC4826]ローゼンバーグ、J.、 "リソース・リストを表すための拡張マークアップ言語（XML）フォーマット"、RFC 4826、2007年5月。
[RFC5363] Camarillo, G. and A.B. Roach, "Framework and Security Considerations for Session Initiation Protocol (SIP) URI-List Services", RFC 5363, October 2008.
[RFC5363]キャマリロ、G.およびA.B.ローチ、RFC 5363、2008年10月「セッション開始プロトコル（SIP）URIリストサービスのためのフレームワークとセキュリティの考慮事項」。
[RFC5364] Garcia-Martin, M. and G. Camarillo, "Extensible Markup Language (XML) Format Extension for Representing Copy Control Attributes in Resource Lists", RFC 5364, October 2008.
[RFC5364]ガルシア・マーチン、M.およびG.キャマリロ、「コピー制御を表現するための拡張マークアップ言語（XML）形式拡張子リソースリストに属性」、RFC 5364、2008年10月。
[RFC4245] Levin, O. and R. Even, "High-Level Requirements for Tightly Coupled SIP Conferencing", RFC 4245, November 2005.
でも、[RFC4245]レヴィン、O.とR.、 "密結合SIP会議のための高レベルの要件"、RFC 4245、2005年11月。
[RFC4353] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol (SIP)", RFC 4353, February 2006.
[RFC4353]ローゼンバーグ、J.、RFC 4353、2006年2月 "セッション開始プロトコル（SIP）との会議のためのフレームワーク"。
[RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, Ed., "A Session Initiation Protocol (SIP) Event Package for Conference State", RFC 4575, August 2006.
[RFC4575]ローゼンバーグ、J.、Schulzrinneと、H.、およびO.レヴィン、エド。、 "Aセッション開始プロトコル（SIP）の会議の状態のためのイベントパッケージ"、RFC 4575、2006年8月。
Authors' Addresses
著者のアドレス
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland
ゴンサロ・カマリロエリクソンHirsalantie 11 Jorvas 02420フィンランド
EMail: Gonzalo.Camarillo@ericsson.com
メールアドレス：Gonzalo.Camarillo@ericsson.com
Alan Johnston Avaya St. Louis, MO 63124 USA
アラン・ジョンストンアバイアセントルイス、MO 63124 USA
EMail: alan@sipstation.com
メールアドレス：alan@sipstation.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。