[要約] RFC 7082は、Centralized Conferencing Manipulation Protocol（CCMP）の会議フォーカスサポートを示すためのものです。その目的は、CCMPを使用して会議の操作を行うための標準化と指針を提供することです。
Internet Engineering Task Force (IETF) R. Shekh-Yusef
Request for Comments: 7082 Avaya
Category: Informational M. Barnes
ISSN: 2070-1721 Polycom
December 2013
Indication of Conference Focus Support for the Centralized Conferencing Manipulation Protocol (CCMP)
集中会議操作プロトコル（CCMP）の会議フォーカスサポートの表示
Abstract
概要
The Centralized Conferencing Manipulation Protocol (CCMP) document (RFC 6503) defines a way for a client to discover a conference control server that supports CCMP. However, it does not define a way for a client involved in a conference to determine if the conference focus supports CCMP. This information would allow a CCMP-enabled client that joins a conference using SIP to also register for the Centralized Conferencing (XCON) conference event package and take advantage of CCMP operations on the conference.
集中会議操作プロトコル（CCMP）ドキュメント（RFC 6503）は、クライアントがCCMPをサポートする会議制御サーバーを発見する方法を定義しています。ただし、会議に参加しているクライアントが会議のフォーカスがCCMPをサポートしているかどうかを判断する方法は定義していません。この情報により、SIPを使用して会議に参加するCCMP対応クライアントは、集中会議（XCON）会議イベントパッケージにも登録し、会議でのCCMP操作を利用できます。
This document describes two mechanisms, depending upon the need of the User Agent (UA), to address the above limitation. The first mechanism uses the Call-Info header field, and the second mechanism defines a new value for the "purpose" header field parameter in the <service-uris> element in the SIP conferencing event package.
このドキュメントでは、ユーザーエージェント（UA）の必要性に応じて、上記の制限に対処する2つのメカニズムについて説明します。最初のメカニズムはCall-Infoヘッダーフィールドを使用し、2番目のメカニズムはSIP会議イベントパッケージの<service-uris>要素の「purpose」ヘッダーフィールドパラメーターの新しい値を定義します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7082.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7082で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Terminology ................................................3
2. Solutions .......................................................3
2.1. Call-Info ..................................................3
2.2. Service URI Purpose ........................................4
3. Overall Process .................................................5
4. Security Considerations .........................................5
5. IANA Considerations .............................................6
5.1. Call-Info Purpose Registration .............................6
5.2. URI Purpose Registration ...................................6
6. Acknowledgments .................................................6
7. Normative References ............................................7
Appendix A. Other Approaches Considered ............................9
A.1. Feature Tag ................................................9
A.2. Conference URI Purpose .....................................9
RFC 5239 [RFC5239] defines a framework for Centralized Conferencing (XCON), which allows participants to exchange media in a centralized unicast conference. The framework also outlines a set of conferencing protocols for building advanced conferencing applications.
RFC 5239 [RFC5239]は、参加者が集中型ユニキャスト会議でメディアを交換できるようにする集中型会議（XCON）のフレームワークを定義しています。このフレームワークは、高度な会議アプリケーションを構築するための一連の会議プロトコルについても概説しています。
The Centralized Conferencing Manipulation Protocol (CCMP) [RFC6503] allows authenticated and authorized users to create, manipulate, and delete conference objects. Operations on conferences include adding and removing participants and changing their roles, as well as adding and removing media streams and associated end points.
集中会議操作プロトコル（CCMP）[RFC6503]を使用すると、認証および承認されたユーザーが会議オブジェクトを作成、操作、および削除できます。会議の操作には、参加者の追加と削除、役割の変更、メディアストリームと関連するエンドポイントの追加と削除が含まれます。
CCMP defines a way for an XCON-aware client to discover whether a conference control server supports CCMP. However, it does not define a way for a SIP client involved in a conference to determine if the conference focus [RFC4353] supports CCMP. Knowing that a focus supports CCMP would allow a SIP client (that is also XCON aware) that joins a conference using SIP-based conferencing [RFC4579] to also register for the XCON conference event package [RFC6502] and take advantage of CCMP operations on the conference.
CCMPは、XCON対応クライアントが会議制御サーバーがCCMPをサポートしているかどうかを検出する方法を定義します。ただし、会議に関与するSIPクライアントが会議のフォーカス[RFC4353]がCCMPをサポートしているかどうかを判断する方法は定義していません。フォーカスがCCMPをサポートしていることを知っていれば、SIPベースの会議[RFC4579]を使用して会議に参加するSIPクライアント（XCON対応）もXCON会議イベントパッケージ[RFC6502]に登録し、CCMP操作を利用できます。会議。
This document describes two options to address the above limitation, depending on the need of the User Agent (UA). The first option uses the Call-Info [RFC3261] header, which is suitable for application servers that need to discover if a UA supports CCMP. The second option defines a new value for the "purpose" header field parameter in the <service-uris> element in the SIP conferencing event package [RFC4575] that is suitable for a UA that would typically subscribe to the conference event package.
このドキュメントでは、ユーザーエージェント（UA）の必要性に応じて、上記の制限に対処する2つのオプションについて説明します。最初のオプションは、UAがCCMPをサポートするかどうかを検出する必要があるアプリケーションサーバーに適したCall-Info [RFC3261]ヘッダーを使用します。 2番目のオプションは、SIP会議イベントパッケージ[RFC4575]の<service-uris>要素の "purpose"ヘッダーフィールドパラメーターの新しい値を定義します。この値は、通常、会議イベントパッケージにサブスクライブするUAに適しています。
Appendix A has a brief description of other options that we considered as possible solutions. Those other options were not selected, however, because the options described in this document better address the problem we are trying to solve.
付録Aでは、考えられる解決策として検討した他のオプションについて簡単に説明しています。ただし、このドキュメントで説明されているオプションは、解決しようとしている問題により適切に対処できるため、他のオプションは選択されていません。
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 RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
This section defines two mechanisms that can be used by a SIP UA to discover whether the conference that a client has joined, per the SIP signaling procedures defined in [RFC4579], supports CCMP. Specifically, the mechanisms allow the client to know that the URI representing the conference focus, as defined in [RFC4579], is an XCON-URI as defined in [RFC6501].
このセクションでは、[RFC4579]で定義されているSIPシグナリング手順に従って、クライアントが参加した会議がCCMPをサポートしているかどうかを検出するためにSIP UAが使用できる2つのメカニズムを定義します。具体的には、メカニズムにより、[RFC4579]で定義されている会議のフォーカスを表すURIが[RFC6501]で定義されているXCON-URIであることをクライアントが知ることができます。
This approach uses the Call-Info header in various requests and responses.
このアプローチでは、さまざまな要求と応答でCall-Infoヘッダーを使用します。
The Call-Info header consists of two parts: a URI and a "purpose" header field parameter. The URI provides the XCON-URI of the conference focus, and a new value for the "purpose" header field parameter indicates that the conference focus supports CCMP.
Call-Infoヘッダーは、URIと「目的」ヘッダーフィールドパラメーターの2つの部分で構成されます。 URIは会議フォーカスのXCON-URIを提供し、「purpose」ヘッダーフィールドパラメータの新しい値は、会議フォーカスがCCMPをサポートすることを示します。
While the XCON-URI by itself should be enough to indicate that the conference focus supports CCMP, the "purpose" header field parameter with a value of 'ccmp' provides an easier way for a UA that does not use the conference event package to discover that the conference focus supports CCMP, without parsing the URI.
XCON-URI自体は、会議のフォーカスがCCMPをサポートしていることを示すのに十分でなければなりませんが、「ccmp」の値を持つ「目的」ヘッダーフィールドパラメーターは、会議イベントパッケージを使用しないUAがより簡単に発見できる方法を提供します会議の焦点は、URIを解析せずにCCMPをサポートすること。
The Call-Info header, with the XCON-URI and the "purpose" header field parameter with the 'ccmp' value, can be used with any INVITE request or response and with a response to an OPTIONS request.
XCON-URIと「目的」ヘッダーフィールドパラメーターが「ccmp」値を持つCall-Infoヘッダーは、任意のINVITE要求または応答、およびOPTIONS要求への応答で使用できます。
This approach would be suitable for a UA, e.g., an application server that acts as a Back-to-Back User Agent (B2BUA), that is interested in discovering that a conference focus supports CCMP but does not use the XCON conference event package [RFC6502]. In this case, the application could use the OPTIONS request and discover CCMP support from the response.
このアプローチは、会議のフォーカスがCCMPをサポートしているがXCON会議イベントパッケージを使用していないことを発見することに関心があるUA、たとえばバックツーバックユーザーエージェント（B2BUA）として機能するアプリケーションサーバーに適しています。 RFC6502]。この場合、アプリケーションはOPTIONS要求を使用して、応答からCCMPサポートを検出できます。
This approach would also be suitable for a conference focus that initiates an INVITE request to a SIP UA to add a participant to a conference, as it would allow the conference focus to indicate that it supports CCMP with the INVITE request sent to the UA.
このアプローチは、SIP UAへのINVITE要求を開始して会議に参加者を追加する会議フォーカスにも適しています。これは、UAに送信されるINVITE要求でCCMPをサポートすることを会議フォーカスが示すことを可能にするためです。
The advantage of this approach is the ability to discover that a conference focus supports CCMP, without subscribing to the XCON event package [RFC6502]. The disadvantage is the need, in some cases, for an extra request, i.e., an additional OPTIONS request, to discover that a conference focus supports CCMP.
このアプローチの利点は、XCONイベントパッケージ[RFC6502]に登録しなくても、会議の焦点がCCMPをサポートしていることを発見できることです。欠点は、場合によっては、会議のフォーカスがCCMPをサポートしていることを検出するために、追加の要求、つまり追加のOPTIONS要求が必要になることです。
This approach defines an additional URI 'purpose' of 'ccmp' associated with a <service-uris> element in the SIP conferencing event package. The XCON-URI for the conference is included in the 'uri' element, per the following example:
このアプローチは、SIP会議イベントパッケージの<service-uris>要素に関連付けられた「ccmp」の追加の「目的」URIを定義します。会議のXCON-URIは、次の例のように、「uri」要素に含まれています。
<service-uris>
<entry>
<uri>XCON:conf1@example.com</uri>
<purpose>ccmp</purpose>
</entry>
</service-uris>
The advantage of this approach is that it uses an existing mechanism for extending the <purpose> field of the <service-uris> element in the conferencing event package [RFC4353]. The disadvantage is that it requires the client to subscribe to the conference event package.
このアプローチの利点は、既存のメカニズムを使用して、会議イベントパッケージ[RFC4353]の<service-uris>要素の<purpose>フィールドを拡張することです。欠点は、クライアントが会議イベントパッケージに登録する必要があることです。
This approach would be suitable for a SIP UA that would typically subscribe to the conference event package. Knowing that a conference supports CCMP allows a SIP UA that is XCON aware to make use of the CCMP operations and allows it to subscribe to the XCON event package [RFC6502] to get additional information related to the conference.
このアプローチは、通常、会議イベントパッケージにサブスクライブするSIP UAに適しています。会議がCCMPをサポートしていることを知っていると、XCONに対応するSIP UAがCCMP操作を利用でき、XCONイベントパッケージ[RFC6502]にサブスクライブして、会議に関連する追加情報を取得できます。
CCMP capability is discovered using the two methods described in Section 2. The order in which the two methods are tried depends on whether an implementation subscribes to the conference event package by default.
CCMP機能は、セクション2で説明する2つの方法を使用して検出されます。2つの方法が試行される順序は、実装がデフォルトで会議イベントパッケージにサブスクライブするかどうかによって異なります。
A UA implementation that subscribes to the conference event package can examine the conference description to see if a URI with <purpose>ccmp</purpose> is specified (Section 2.2). An implementation that does not subscribe to the conference event package can perform an OPTIONS query when connecting to the conference server. UAs MUST NOT attempt both methods with the same server.
会議イベントパッケージにサブスクライブするUA実装は、会議の説明を調べて、<purpose> ccmp </ purpose>のURIが指定されているかどうかを確認できます（セクション2.2）。会議イベントパッケージにサブスクライブしない実装は、会議サーバーに接続するときにOPTIONSクエリを実行できます。 UAは同じサーバーで両方の方法を試行してはなりません。
Conference servers MUST reflect the same information using both discovery channels. A server MUST indicate CCMP support through the conference event package if and only if it indicates support through the Call-Info header in OPTIONS responses. This prevents the need for UAs to try both methods.
会議サーバーは、両方の検出チャネルを使用して同じ情報を反映する必要があります。サーバーは、OPTIONS応答のCall-Infoヘッダーを通じてサポートを示す場合にのみ、会議イベントパッケージを通じてCCMPサポートを示す必要があります。これにより、UAが両方の方法を試す必要がなくなります。
This document defines no new headers or data elements; it reuses existing headers and data elements. CCMP already allows a client the ability to discover if a conference server supports CCMP, using a DNS mechanism as defined in [RFC6503] Section 12.4.
このドキュメントでは、新しいヘッダーやデータ要素は定義されていません。既存のヘッダーとデータ要素を再利用します。 CCMPでは、[RFC6503]セクション12.4で定義されているDNSメカニズムを使用して、クライアントが会議サーバーがCCMPをサポートしているかどうかをクライアントが検出できるようになっています。
Thus, the solution options defined in this document do not introduce any new security threats.
したがって、このドキュメントで定義されているソリューションオプションは、新しいセキュリティ上の脅威をもたらしません。
This specification adds a new predefined value "ccmp" for the "purpose" header field parameter of the Call-Info header field. This modifies the registry header field parameters and parameter values by adding this RFC as a reference to the line for header field "Call-Info" and parameter name "purpose":
この仕様は、Call-Infoヘッダーフィールドの「purpose」ヘッダーフィールドパラメータに新しい事前定義値「ccmp」を追加します。これにより、このRFCをヘッダーフィールド "Call-Info"およびパラメーター名 "purpose"の行への参照として追加することにより、レジストリヘッダーフィールドのパラメーターとパラメーター値が変更されます。
Header Field: Call-Info
ヘッダーフィールド：Call-Info
Parameter Name: purpose
パラメータ名：目的
Predefined Values: yes
定義済みの値：はい
Reference: [RFC3261] [RFC5367] [RFC6910] [RFC6993] [RFC7082]
参照：[RFC3261] [RFC5367] [RFC6910] [RFC6993] [RFC7082]
This specification adds a new predefined value "ccmp" to the "URI Purposes" subregistry, which defines XML elements to be encoded in the conference event package [RFC4575].
この仕様は、新しい事前定義値「ccmp」を「URI目的」サブレジストリに追加します。サブレジストリは、会議イベントパッケージ[RFC4575]でエンコードされるXML要素を定義します。
This modifies the registry as follows:
これにより、レジストリが次のように変更されます。
Value: ccmp
値：ccmp
Description: The URI can be used to indicate that the conference focus supports CCMP.
説明：URIを使用して、会議のフォーカスがCCMPをサポートしていることを示すことができます。
Reference: [RFC7082]
参照：[RFC7082]
The authors would like to thank Alan Johnston, Robert Sparks, Cullen Jennings, Glenn Parsons, Ben Campbell, Barry Leiba, Spencer Dawkins, Sean Turner, Pete Resnick, and Adrian Farrel for their careful review and feedback.
著者は、慎重なレビューとフィードバックを提供してくれたAlan Johnston、Robert Sparks、Cullen Jennings、Glenn Parsons、Ben Campbell、Barry Leiba、Spencer Dawkins、Sean Turner、Pete Resnick、およびAdrian Farrelに感謝します。
Special thanks to Adam Roach for his thorough review, comments, and suggestions. Special thanks also to Richard Barnes for his review and for the text he provided for Section 3 of this document.
Adam Roach氏の徹底したレビュー、コメント、提案に感謝します。 Richard Barnes氏のレビューと、このドキュメントのセクション3に提供したテキストにも感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：セッション開始プロトコル」 、RFC 3261、2002年6月。
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004.
[RFC3840] Rosenberg、J.、Schulzrinne、H。、およびP. Kyzivat、「Indicating User Agent Capabilities in the Session Initiation Protocol（SIP）」、RFC 3840、2004年8月。
[RFC4353] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol (SIP)", RFC 4353, February 2006.
[RFC4353] Rosenberg、J。、「Session Initiation Protocol（SIP）との会議のフレームワーク」、RFC 4353、2006年2月。
[RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, Ed., "A Session Initiation Protocol (SIP) Event Package for Conference State", RFC 4575, August 2006.
[RFC4575] Rosenberg、J.、Schulzrinne、H。、およびO. Levin、編、「会議状態用のSession Initiation Protocol（SIP）イベントパッケージ」、RFC 4575、2006年8月。
[RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol (SIP) Call Control - Conferencing for User Agents", BCP 119, RFC 4579, August 2006.
[RFC4579] Johnston、A.およびO. Levin、「Session Initiation Protocol（SIP）Call Control-Conferencing for User Agents」、BCP 119、RFC 4579、2006年8月。
[RFC5239] Barnes, M., Boulton, C., and O. Levin, "A Framework for Centralized Conferencing", RFC 5239, June 2008.
[RFC5239] Barnes、M.、Boulton、C。、およびO. Levin、「集中会議のフレームワーク」、RFC 5239、2008年6月。
[RFC5367] Camarillo, G., Roach, A., and O. Levin, "Subscriptions to Request-Contained Resource Lists in the Session Initiation Protocol (SIP)", RFC 5367, October 2008.
[RFC5367] Camarillo、G.、Roach、A。、およびO. Levin、「Session Initiation Protocol（SIP）のリクエストに含まれるリソースリストへのサブスクリプション」、RFC 5367、2008年10月。
[RFC6501] Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen, "Conference Information Data Model for Centralized Conferencing (XCON)", RFC 6501, March 2012.
[RFC6501] Novo、O.、Camarillo、G.、Morgan、D。、およびJ. Urpalainen、「集中会議（XCON）の会議情報データモデル」、RFC 6501、2012年3月。
[RFC6502] Camarillo, G., Srinivasan, S., Even, R., and J. Urpalainen, "Conference Event Package Data Format Extension for Centralized Conferencing (XCON)", RFC 6502, March 2012.
[RFC6502] Camarillo、G.、Srinivasan、S.、Even、R。、およびJ. Urpalainen、「集中会議（XCON）の会議イベントパッケージデータ形式拡張」、RFC 6502、2012年3月。
[RFC6503] Barnes, M., Boulton, C., Romano, S., and H. Schulzrinne, "Centralized Conferencing Manipulation Protocol", RFC 6503, March 2012.
[RFC6503] Barnes、M.、Boulton、C.、Romano、S。、およびH. Schulzrinne、「Centralized Conferencing Manipulation Protocol」、RFC 6503、2012年3月。
[RFC6910] Worley, D., Huelsemann, M., Jesske, R., and D. Alexeitsev, "Completion of Calls for the Session Initiation Protocol (SIP)", RFC 6910, April 2013.
[RFC6910] Worley、D.、Huelsemann、M.、Jesske、R。、およびD. Alexeitsev、「Completion of Calls for the Session Initiation Protocol（SIP）」、RFC 6910、2013年4月。
[RFC6993] Saint-Andre, P., "Instant Messaging and Presence Purpose for the Call-Info Header Field in the Session Initiation Protocol (SIP)", RFC 6993, July 2013.
[RFC6993] Saint-Andre、P。、「Session Initiation Protocol（SIP）のCall-Infoヘッダーフィールドのインスタントメッセージングとプレゼンスの目的」、RFC 6993、2013年7月。
The following two options were considered as possible solutions but were not selected because the options described in this document better address the problem we are trying to solve.
次の2つのオプションは考えられる解決策と見なされていましたが、このドキュメントで説明されているオプションは、解決しようとしている問題により適切に対処できるため、選択されませんでした。
This approach defines a feature parameter 'ccmp' to indicate that a SIP dialog belongs to a conference that supports CCMP. The use of feature parameters in Contact header fields to describe the characteristics and capabilities of a UA is described in the User Agent Capabilities document [RFC3840].
このアプローチは、SIPダイアログがCCMPをサポートする会議に属していることを示す機能パラメーター「ccmp」を定義します。 UAの特性と機能を説明するためのContactヘッダーフィールドでの機能パラメーターの使用は、ユーザーエージェント機能のドキュメント[RFC3840]で説明されています。
The conference focus behavior regarding the handling of the 'ccmp' feature is the same as the behavior for the handling of the 'isfocus' feature parameter. In session establishment, a conference focus MUST include the 'ccmp' feature parameter in the Contact header field unless the conference focus wishes to hide the fact that it is a conference focus.
'ccmp'機能の処理に関する会議フォーカスの動作は、 'isfocus'機能パラメーターの処理の動作と同じです。セッションの確立では、会議のフォーカスが会議のフォーカスであるという事実を隠したくない場合を除き、会議のフォーカスはContactヘッダーフィールドに「ccmp」機能パラメータを含める必要があります。
The advantages of this approach are a one-step discovery of the conference focus and its support for the 'ccmp' feature and the fact that it can be used in response to an OPTIONS request, and that it enables the discovery of the 'ccmp' capability by any network element that does not need the conference event package. The disadvantage is the definition of a new feature parameter.
このアプローチの利点は、会議の焦点を1ステップで発見し、「ccmp」機能をサポートすることと、OPTIONSリクエストに応答して使用できること、および「ccmp」の発見を可能にすることです。会議イベントパッケージを必要としないネットワーク要素による機能。欠点は、新しい機能パラメーターの定義です。
This approach defines an additional URI 'purpose' of 'ccmp' associated with a 'conf-uris' element in the SIP conferencing event package.
このアプローチは、SIP会議イベントパッケージの「conf-uris」要素に関連付けられた「ccmp」の追加の「目的」URIを定義します。
ccmp: Indicates that the conference focus represented by this URI supports 'ccmp'; this in turn allows a client to use CCMP to manipulate the conference. This URI MUST be an XCON-URI as defined in the XCON data model specification [RFC6501].
ccmp：このURIで表される会議のフォーカスが「ccmp」をサポートすることを示します。これにより、クライアントはCCMPを使用して会議を操作できます。このURIは、XCONデータモデル仕様[RFC6501]で定義されているXCON-URIである必要があります。
<conf-uris>
<entry>
<uri>XCON:conf1@example.com</uri>
<display-text>whatever</display-text>
<purpose>ccmp</purpose>
</entry>
</conf-uris>
The advantage of the SIP conference event package options is the use of an existing mechanism for extending the <purpose> field of the <service-uris> or <conf-uris> elements. The disadvantage is the requirement that the client register for the conference event package.
SIP会議イベントパッケージオプションの利点は、<service-uris>または<conf-uris>要素の<purpose>フィールドを拡張するための既存のメカニズムを使用することです。欠点は、クライアントが会議イベントパッケージに登録する必要があることです。
Authors' Addresses
著者のアドレス
Rifaat Shekh-Yusef Avaya 250 Sidney Street Belleville, Ontario Canada
Rifat Sheikh-Youssef ಸ್ಟ್ರೀಟ್ Sydney Streetベルヴィルカナダオンタリオ州
Phone: +1-613-967-5267
EMail: rifaat.ietf@gmail.com
Mary Barnes Polycom TX US
メアリーバーンズポリコムTX US
EMail: mary.ietf.barnes@gmail.com