RFC 3840 - Indicating User Agent Capabilities in the Session Initiation Protocol (SIP) 日本語訳

URL : https://tools.ietf.org/html/rfc3840
タイトル : RFC 3840 - セッション開始プロトコル（SIP）で示すユーザエージェント機能
翻訳編集 : 自動生成

Network Working Group                                       J. Rosenberg
Request for Comments: 3840                                   dynamicsoft
Category: Standards Track                                 H. Schulzrinne
                                                     Columbia University
                                                              P. Kyzivat
                                                           Cisco Systems
                                                             August 2004

                 Indicating User Agent Capabilities 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）の最新版を参照してください。このメモの配布は無制限です。

著作権表示

著作権（C）インターネット協会（2004）。

Abstract

抽象

This specification defines mechanisms by which a Session Initiation Protocol (SIP) user agent can convey its capabilities and characteristics to other user agents and to the registrar for its domain. This information is conveyed as parameters of the Contact header field.

この仕様は、セッション開始プロトコル（SIP）ユーザエージェントは、他のユーザエージェントに、そのドメインのレジストラにその能力及び特性を伝えることが可能なメカニズムを定義します。この情報は、Contactヘッダフィールドのパラメータとして搬送されます。

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Usage of the Content Negotiation Framework . . . . . . . . . .  6
   5.  Computing Capabilities . . . . . . . . . . . . . . . . . . . .  7
   6.  Expressing Capabilities in a Registration  . . . . . . . . . . 10
   7.  Indicating Feature Sets in Remote Target URIs  . . . . . . . . 12
   8.  OPTIONS Processing . . . . . . . . . . . . . . . . . . . . . . 13
   9.  Contact Header Field . . . . . . . . . . . . . . . . . . . . . 13
   10. Media Feature Tag Definitions  . . . . . . . . . . . . . . . . 14
       10.1.  Audio . . . . . . . . . . . . . . . . . . . . . . . . . 15
       10.2.  Application . . . . . . . . . . . . . . . . . . . . . . 16
       10.3.  Data. . . . . . . . . . . . . . . . . . . . . . . . . . 16
       10.4.  Control . . . . . . . . . . . . . . . . . . . . . . . . 17
       10.5.  Video . . . . . . . . . . . . . . . . . . . . . . . . . 17
       10.6.  Text. . . . . . . . . . . . . . . . . . . . . . . . . . 18
       10.7.  Automata. . . . . . . . . . . . . . . . . . . . . . . . 18
       10.8.  Class . . . . . . . . . . . . . . . . . . . . . . . . . 19
       10.9.  Duplex. . . . . . . . . . . . . . . . . . . . . . . . . 20
       10.10. Mobility. . . . . . . . . . . . . . . . . . . . . . . . 20
       10.11. Description . . . . . . . . . . . . . . . . . . . . . . 21
       10.12. Event Packages. . . . . . . . . . . . . . . . . . . . . 22
       10.13. Priority. . . . . . . . . . . . . . . . . . . . . . . . 22
       10.14. Methods . . . . . . . . . . . . . . . . . . . . . . . . 23
       10.15. Extensions. . . . . . . . . . . . . . . . . . . . . . . 24
       10.16. Schemes . . . . . . . . . . . . . . . . . . . . . . . . 24
       10.17. Actor . . . . . . . . . . . . . . . . . . . . . . . . . 25
       10.18. Is Focus. . . . . . . . . . . . . . . . . . . . . . . . 26
   11. Security Considerations  . . . . . . . . . . . . . . . . . . . 26
       11.1.  Considerations for Media Feature Tags . . . . . . . . . 26
       11.2.  Considerations for Registrations. . . . . . . . . . . . 27
       11.3.  Considerations for OPTIONS Responses. . . . . . . . . . 28
       11.4.  Considerations for Dialog Initiating Messages . . . . . 28
   12. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 28
       12.1.  SIP Media Feature Tag Registration Tree . . . . . . . . 28
       12.2.  Media Feature Tags. . . . . . . . . . . . . . . . . . . 29
       12.3.  SIP Option Tag. . . . . . . . . . . . . . . . . . . . . 30
   13. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 30
   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
       14.1.  Normative References. . . . . . . . . . . . . . . . . . 31
       14.2.  Informative References. . . . . . . . . . . . . . . . . 31
   Appendix.  Overview of RFC 2533. . . . . . . . . . . . . . . . . . 33
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
   Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 36

1. Introduction

1. はじめに

Session Initiation Protocol (SIP) [1] user agents vary widely in their capabilities and in the types of devices they represent. Frequently, it is important for another SIP element to learn the capabilities and characteristics of a SIP UA. Some of the applications of this information include:

セッション開始プロトコル（SIP）[1]ユーザエージェントがその機能およびそれらが表すデバイスの種類に広く変化。別のSIP要素は、SIP UAの能力や特性を学習するためにしばしば、それが重要です。この情報のアプリケーションの一部を以下に示します。

o One user agent, a PC-based application, is communicating with another that is embedded in a limited-function device. The PC would like to be able to "grey out" those components of the user interface that represent features or capabilities not supported by its peer. To do that, there needs to be a way to exchange capability information within a dialog.

一方、ユーザエージェント、PCベースのアプリケーションO、限られた機能デバイスに埋め込まれている相互に通信しています。 PCはピアでサポートされていない機能や能力を表すユーザ・インタフェースのこれらのコンポーネントを「灰色」できるようにしたいと思います。これを行うには、ダイアログ内の能力情報を交換する方法が必要です。

o A user has two devices at their disposal. One is a videophone, and the other, a voice-only wireless phone. A caller wants to interact with the user using video. As such, they would like their call preferentially routed to the device which supports video. To do this, the INVITE request can contain parameters that express a preference for routing to a device with the specified capabilities [11].

Oユーザーが自由に二つのデバイスを持っています。一つは、テレビ電話、および他、音声のみの携帯電話です。呼び出し側は、ビデオを使用して、ユーザーとの対話を望んでいます。そのため、彼らは優先的にビデオをサポートするデバイスにルーティングされた彼らのコールをしたいと思います。これを行うために、INVITE要求は、指定された機能[11]を用いてデバイスにルーティングするための嗜好を表現するパラメータを含むことができます。

o A network application would like to asynchronously send information to a user agent in a MESSAGE [16] request. However, before sending it, they would like to know if the UA has the capabilities necessary to receive the message. To do that, they would ideally query a user database managed by the domain which holds such information. Population of such a database would require that a UA convey its capabilities as part of its registration. Thus, there is a need for conveying capabilities in REGISTER requests.

Oネットワーク・アプリケーションは、非同期メッセージ[16]要求のユーザエージェントに情報を送りたいです。しかし、それを送信する前に、彼らはUAがメッセージを受信するために必要な能力を持っているかどうかを知りたいと思います。そのためには、彼らは、理想的には、このような情報を保持しているドメインによって管理されているユーザデータベースを照会します。このようなデータベースの人口は、UAはその登録の一部として、その機能を伝えることが必要となります。このように、REGISTERリクエストで能力を搬送する必要があります。

SIP has some support for expression of capabilities. The Allow, Accept, Accept-Language, and Supported header fields convey some information about the capabilities of a user agent. However, these header fields convey only a small part of the information that is needed. They do not provide a general framework for expression of capabilities. Furthermore, they only specify capabilities indirectly; the header fields really indicate the capabilities of the UA as they apply to this request. SIP also has no ability to convey characteristics, that is, information that describes a UA.

SIPは、機能の発現のためのいくつかサポートしています。、許可受け入れる、受け入れ言語、およびサポートされているヘッダフィールドは、ユーザエージェントの機能に関するいくつかの情報を伝えます。しかし、これらのヘッダフィールドが必要とされる情報のほんの一部を伝えます。彼らは、機能の発現のための一般的なフレームワークを提供していません。さらに、彼らは間接的にしか機能を指定します。彼らはこの要求に適用されるヘッダフィールドは、実際にUAの能力を示しています。 SIPはまた、UAを記述する特性を伝達する能力、すなわち、情報を持っていません。

As a result, this specification provides a more general framework for an indication of capabilities and characteristics in SIP. Capability and characteristic information about a UA is carried as parameters of the Contact header field. These parameters can be used within REGISTER requests and responses, OPTIONS responses, and requests and responses that create dialogs (such as INVITE).

結果として、本明細書は、SIPにおける機能及び特性を示すためのより一般的なフレームワークを提供します。 UA約能力及び特性情報は、Contactヘッダフィールドのパラメータとして実施されます。これらのパラメータは、（例えば、INVITEのような）ダイアログを作成REGISTER要求および応答、OPTIONSの応答、および要求および応答内で使用することができます。

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 BCP 14, RFC 2119 [2] and indicate requirement levels for compliant implementations.

この文書では、キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "NOT SHALL"、 "推奨"、 "すべきではない" "べきである" "ないものと"、 "MAY"、および "オプション" BCP 14、RFC 2119に記載されているように[2]に解釈されるべきであり、対応する実装の要求レベルを示します。

3. Definitions

3.定義

Feature: As defined in RFC 2703 [17], a piece of information about the media handling properties of a message passing system component or of a data resource. For example, the SIP methods supported by a UA represent a feature.

特徴：RFC 2703 [17]、システムコンポーネントまたはデータ・リソースのメッセージパッシングのメディア処理特性に関する情報の一片に定義された通りです。例えば、UAによってサポートされるSIPメソッドは機能を表します。

Feature Tag: As defined in RFC 2703 [17], a feature tag is a name that identifies a feature. An example is "sip.methods".

特集タグ：[17] RFC 2703で定義されているように、フィーチャータグは、機能を識別する名前です。例では、「sip.methods」です。

Media Feature: As defined in RFC 2703, [17], a media feature is information that indicates facilities assumed to be available for the message content to be properly rendered or otherwise presented. Media features are not intended to include information that affects message transmission.

メディア機能：RFC 2703で定義されるように、[17]、メディア機能が正しくレンダリングされたまたは他の方法で提示されるメッセージ内容のために利用可能であると仮定施設を示す情報です。メディア機能は、メッセージ送信に影響を与えた情報を含むことが意図されていません。

In the context of this specification, a media feature is information that indicates facilities for handling SIP requests, rather than specifically for content. In that sense, it is used synonymously with feature.

本明細書の文脈では、メディア機能ではなく、具体的にコンテンツの場合よりも、SIP要求を処理するための設備を示す情報です。その意味では、機能と同義に使用されています。

Feature Collection: As defined in RFC 2533 [4], a feature collection is a collection of different media features and associated values. This might be viewed as describing a specific rendering of a specific instance of a document or resource by a specific recipient.

フィーチャーコレクション：RFC 2533で定義されているように、[4]、機能のコレクションは、さまざまなメディア機能と関連する値の集合です。これは、特定の受信者が文書やリソースの特定のインスタンスの特定のレンダリングを説明するものとして見られるかもしれません。

Feature Set: As defined in RFC 2703 [17], a feature set is information about a sender, recipient, or other participant in a message transfer which describes the set of features that it can handle. Where a 'feature' describes a single identified attribute of a resource, a 'feature set' describes a full set of possible attributes.

機能セット：RFC 2703で定義されているように[17]、機能セットは、送信者、受信者、またはそれを扱うことができる機能のセットを説明するメッセージ転送中に他の参加者に関する情報です。「機能が」リソースの単一識別属性を記述する場合、「機能セットは、」可能な属性の完全なセットを記述します。

Feature Parameters: A set of SIP header field parameters that can appear in the Contact header field. The feature parameters represent an encoding of a feature set. Each set of feature parameters maps to a feature set predicate.

特徴パラメータ：Contactヘッダーフィールドに表示できるSIPヘッダフィールドパラメータのセット。特徴量は、特徴セットのエンコーディングを表します。特徴パラメータの各セットは、機能セットの述語にマップされます。

Capability: As defined in RFC 2703 [17], a capability is an attribute of a sender or receiver (often the receiver) which indicates an ability to generate or process a particular type of message content. A capability is distinct from a characteristic in that a capability may or may not be utilized in any particular call, whereas a characteristic is a non-negotiable property of a UA. SIP itself will often negotiate whether or not capabilities are used in a call.

能力：RFC 2703 [17]で定義されているように、力が生成またはメッセージコンテンツの特定のタイプを処理する能力を示す送信側または受信側（しばしば受信機）の属性です。特性は、UAの非交渉性であるのに対し能力がその中特性能力とは別個であるか、任意の特定のコールに利用してもしなくてもよいです。 SIP自体は、多くの場合、機能が呼び出しに使用されているかどうかを交渉します。

Characteristic: A characteristic is like a capability, but describes an aspect of a UA which is not negotiable. As an example, whether or not a UA is a mobile phone is a characteristic, not a capability. The semantics of this specification do not differentiate between capability and characteristic, but the distinction is useful for illustrative purposes. Indeed, in the text below, when we say "capability", it refers to both capabilities and characteristics, unless the text explicitly says otherwise.

特性：特性が機能に似ているが、交渉可能でないUAの態様を記載しています。一例として、UAは、携帯電話であるか否かが特徴ではない機能です。この仕様のセマンティクスは、能力と特性を区別しませんが、区別は説明の目的のために有用です。私たちは、「機能」を言うときにテキストが明示的に述べていない限り、実際に、以下のテキストで、それは、機能と特性の両方を意味します。

Filter: A single expression in a feature set predicate.

フィルタ：機能セットの述語で単一の式。

Simple Filter: An expression in a feature set predicate which is a comparison (equality or inequality) of a feature tag against a feature value.

単純なフィルタ：特徴量に対して特徴タグの比較（等しいか等しくないか）である特徴セット述部での発現。

Disjunction: A boolean OR operation across some number of terms.

和：用語のいくつかの数の間でブールOR演算。

Conjunction: A boolean AND operation across some number of terms.

接続詞：用語のいくつかの数の間でブールAND演算。

Predicate: A boolean expression.

述語：ブール式。

Feature Set Predicate: From RFC 2533 [4], a feature set predicate is a function of an arbitrary feature collection value which returns a Boolean result. A TRUE result is taken to mean that the corresponding feature collection belongs to some set of media feature handling capabilities defined by this predicate.

機能セット述語は：RFC 2533から[4]、機能セット述語がブール型の結果を返す任意の機能のコレクション値の関数です。 TRUEの結果は、対応する機能コレクションは、この述語によって定義されたメディア機能の処理機能のいくつかのセットに属することを意味するものと解釈されます。

Contact Predicate: The feature set predicate associated with a URI registered in the Contact header field of a REGISTER request. The contact predicate is derived from the feature parameters in the Contact header field.

接触述語：REGISTER要求のContactヘッダフィールドに登録されたURIに関連付けられた機能セット述語。接触述語は、Contactヘッダーフィールドにおける特徴パラメータから導出されます。

4. Usage of the Content Negotiation Framework

コンテントネゴシエーションFrameworkの4使い方

This specification makes heavy use of the terminology and concepts in the content negotiation work carried out within the IETF, and documented in several RFCs. The ones relevant to this specification are RFC 2506 [3], which provides a template for registering media feature tags, RFC 2533 [4], which presents a syntax and matching algorithm for media feature sets, RFC 2738 [5], which provides a minor update to RFC 2533, and RFC 2703 [17], which provides a general framework for content negotiation.

この仕様は、IETF内で行わコンテンツネゴシエーション作業中の用語や概念を多用して、いくつかのRFCで文書化。本明細書に関連するものは、RFC 2506 [3]は、メディア特徴タグを登録するためのテンプレートを提供する、RFC 2533 [4]は、メディア機能セット、RFC 2738の構文とマッチングアルゴリズムを提示している[5]、A提供していますRFC 2533、およびRFC 2703とマイナーアップデート[17]、コンテンツネゴシエーションのための一般的なフレームワークを提供します。

In case the reader does not have the time to read those specifications, Appendix A provides a brief overview of the concepts and terminology in those documents that is critical for understanding this specification.

読者は、これらの仕様を読む時間を持っていない場合は、付録Aには、この仕様を理解するために重要であるそれらのドキュメント内の概念と用語の概要を説明します。

Since the content negotiation work was primarily meant to apply to documents or other resources with a set of possible renderings, it is not immediately apparent how it is used to model SIP user agents. A feature set is composed of a set of feature collections, each of which represents a specific rendering supported by the entity described by the feature set. In the context of a SIP user agent, a feature collection represents an instantaneous modality. That is, if you look at the run time processing of a SIP UA and take a snapshot in time, the feature collection describes what it is doing at that very instant.

コンテンツネゴシエーション作業は主に可能なレンダリングのセットで、文書やその他のリソースに適用するためのものだったので、SIPユーザエージェントをモデル化するために使用される方法をすぐに明らかではありません。機能セットは、特徴セットによって記述されるエンティティによってサポートされる特定のレンダリングを表しそれぞれが機能コレクションのセット、から構成されています。 SIPユーザエージェントのコンテキストでは、機能コレクションは瞬時モダリティを表します。それはあなたがSIP UAの実行時の処理を見て、時間内にスナップショットを取る場合、機能のコレクションは、それは非常にインスタントことで行っていることを説明しています。

This model is important, since it provides guidance on how to determine whether something is a value for a particular feature tag, or a feature tag by itself. If two properties can be exhibited by a UA simultaneously so that both are present in an instantaneous modality, they need to be represented by separate media feature tags. For example, a UA may be able to support some number of media types - audio, video, and control. Should each of these be different values for a single "media-types" feature tag, or should each of them be a separate boolean feature tag? The model provides the answer. Since, at any instance in time, a UA could be handling both audio and video, they need to be separate media feature tags. However, the SIP methods supported by a UA can each be represented as different values for the same media feature tag (the "sip.methods" tag), because fundamentally, a UA processes a single request at a time. It may be multi-threading, so that it appears that this is not so, but at a purely functional level, it is true.

それは何かが特定の機能タグ、またはそれ自体による特徴タグの値であるかどうかを確認する方法についてのガイダンスを提供するので、このモデルは、重要です。両者が瞬時モダリティに存在しているように、2つの特性を同時にUAによって発揮させることができるならば、彼らは別のメディア特徴タグで表現する必要があります。オーディオ、ビデオ、および制御 - 例えば、UAは、メディアタイプのいくつかの数をサポートすることができるかもしれません。これらのそれぞれは、単一の「メディアの種類」機能タグに異なる値でなければならない、またはそれらのそれぞれが別々のブール機能タグすべきですか？モデルは、答えを提供します。時間内の任意のインスタンスで、UAは、オーディオとビデオの両方を扱うことができ、以来、彼らは別のメディア特徴タグである必要があります。基本的に、UAは、一度に単一の要求を処理するためしかし、UAによってサポートされるSIP方法はそれぞれ、同じメディア特徴タグの異なる値（「sip.methods」タグ）として表すことができます。これはそうではなく、純粋に機能的なレベルでは、それが真実であることを表示されるように、それは、マルチスレッドかもしれません。

Clearly, there are weaknesses in this model, but it serves as a useful guideline for applying the concepts of RFC 2533 to the problem at hand.

明らかに、そこにこのモデルの弱点がありますが、それは当面の問題にRFC 2533の概念を適用するための便利な指針として機能します。

5. Computing Capabilities

5.コンピューティング機能

To construct a set of Contact header field parameters that indicate capabilities, a UA constructs a feature predicate for that contact. This process is described in terms of RFC 2533 [4] (and its minor update, RFC 2738 [5]) syntax and constructs, followed by a conversion to the syntax used in this specification. However, this represents a logical flow of processing. There is no requirement that an implementation actually use RFC 2533 syntax as an intermediate step.

能力を示すContactヘッダーフィールドパラメータのセットを構築するために、UAは、その連絡先の機能述語を構築します。このプロセスは、RFC 2533の観点から説明されている[4]（およびそのマイナーアップデート、RFC 2738 [5]）構文及び構築物、本明細書で使用される構文に変換しました。しかしながら、これは、処理の論理フローを表します。実装は、実際に中間ステップとしてRFC 2533の構文を使用する必要はありません。

A UA MAY use any feature tags that are registered through IANA in the SIP tree (Established in Section 12.1), IETF, or global trees [3]; this document registers several into the SIP tree. The feature tags discussed in this specification are referred to as base tags. While other tags can be used, in order to identify them as feature parameters (as opposed to parameters for another SIP extension), they are encoded with a leading "+" sign in the Contact header field. It is also permissible to use the URI tree [3] for expressing vendor-specific feature tags. Feature tags in any other trees created through IANA MAY also be used.

UAは、IETF、またはグローバルツリー[3]（セクション12.1に設立された）SIPツリーにIANAによって登録された任意の特徴タグを使用することができます。この文書は、SIPツリーにいくつか登録されます。本明細書で論じられる特徴タグは、ベースタグと呼ばれます。他のタグは、特徴パラメータ（他のSIP拡張のためのパラメータとは対照的に）としてそれらを識別するために、使用することができるが、それらは、コンタクトヘッダフィールドの先頭の「+」記号で符号化されます。ベンダー固有の機能タグを表現するために、[3] URIツリーを使用することも許されます。 IANAによって作成された他の木での特徴タグを使用することもできます。

When using the "sip.methods" feature tag, a UA MUST NOT include values that correspond to methods not standardized in IETF standards track RFCs. When using the "sip.events" feature tag, a UA MUST NOT include values that correspond to event packages not standardized in IETF standards track RFCs. When using the "sip.schemes" feature tag, a UA MUST NOT include values that correspond to schemes not standardized in IETF standards track RFCs. When using the "sip.extensions" feature tag, a UA MUST NOT include values that correspond to option tags not standardized in IETF standards track RFCs.

「sip.methods」フィーチャータグを使用している場合、UAは、IETF標準トラックRFCで標準化されていない方法に対応する値を含んではいけません。「sip.events」フィーチャータグを使用している場合、UAは、IETF標準トラックRFCで標準化されていないイベントパッケージに対応する値を含んではいけません。「sip.schemes」フィーチャータグを使用している場合、UAは、IETF標準トラックRFCで標準化されていないスキームに対応する値を含んではいけません。「sip.extensions」フィーチャータグを使用している場合、UAは、RFCを追跡するIETF規格で標準化されていないオプションタグに対応する値を含んではいけません。

Note that the "sip.schemes" feature tag does not indicate the scheme of the registered URI. Rather, it indicates schemes that a UA is capable of sending requests to, should such a URI be received in a web page or Contact header field of a redirect response.

「sip.schemes」フィーチャータグが登録されたURIのスキームを示すものではありませんので注意してください。むしろ、UAは、そのようなURIは、リダイレクト応答のウェブページまたは連絡先ヘッダフィールドに受信されなければならないに要求を送信することができる方式を示します。

It is RECOMMENDED that a UA provide complete information in its contact predicate. That is, it SHOULD provide information on as many feature tags as possible. The mechanisms in this specification work best when user agents register complete feature sets. Furthermore, when a UA registers values for a particular feature tag, it MUST list all values that it supports. For example, when including the "sip.methods" feature tag, a UA MUST list all methods it supports.

UAは、その接触述語で完全な情報を提供することを推奨しています。つまり、できるだけ多くの機能タグに情報を提供すべきで、です。この仕様の作品でメカニズムは最高のユーザーエージェントは、完全な機能セットを登録するとき。 UAは、特定の機能タグの値を登録する際にさらに、それがサポートしているすべての値をリストする必要があります。「sip.methods」機能タグを含むとき、例えば、UAはそれがサポートするすべてのメソッドをリストする必要があります。

The contact predicate constructed by a UA MUST be an AND of terms (called a conjunction). Each term is either an OR (called a disjunction) of simple filters or negations of simple filters, or a single simple filter or negation of a single filter. In the case of a disjunction, each filter in the disjunction MUST indicate feature values for the same feature tag (i.e., the disjunction represents a set of values for a particular feature tag), while each element of the conjunction MUST be for a different feature tag. Each simple filter can be an equality, or in the case of numeric feature tags, an inequality or range. If a string (as defined in RFC 2533 [4]) is used as the value of a simple filter, that value MUST NOT include the "<" or ">" characters, the simple filter MUST NOT be negated, and it MUST be the only simple filter for that particular feature tag. This contact predicate is then converted to a list of feature parameters, following the procedure outlined below.

UAによって構築接触述語は、（組み合わせと呼ばれる）の用語でなければなりません。各用語は、単純なフィルタの簡単なフィルタまたは否定のOR（論理和と呼ばれる）、または単一のフィルタの単一単純なフィルタまたは否定のいずれかです。組み合わせの各要素は、異なる機能のためになければならないが論理和の場合には、論理和の各フィルタは、（すなわち、論理和が特定の特徴タグの値の集合を表す）同じ特徴タグの特徴値を示さなければなりません鬼ごっこ。各単純なフィルタは平等、または数値フィーチャータグの場合には、不平等または範囲であることもできます。文字列（RFC 2533で定義されている[4]）単純なフィルタの値として使用される場合、その値が「<」や「>」の文字を含んではいけません、単純なフィルタを否定してはいけません、それがなければなりませんその特定の機能タグのための唯一の単純なフィルタ。この接触述語は、以下の概略を示した手順に従い、特徴パラメータのリストに変換されます。

The contact predicate is a conjunction of terms. Each term indicates constraints on a single feature tag, and each term is represented by a separate feature parameter that will be present in the Contact header field. The syntax of this parameter depends on the feature tag. Each forward slash in the feature tag is converted to a single quote, and each colon are converted to an exclamation point. For the base tags - that is, those feature tags documented in this specification (sip.audio, sip.automata, sip.class, sip.duplex, sip.data, sip.control, sip.mobility, sip.description, sip.events, sip.priority, sip.methods, sip.extensions, sip.schemes, sip.application, sip.video, language, type, sip.isfocus, sip.actor and sip.text), the leading "sip.", if present, is stripped. For feature tags not in this list, the leading "sip." MUST NOT be stripped if present, and indeed, a plus sign ("+") MUST be added as the first character of the Contact header field parameter. The result is the feature parameter name. As a result of these rules, the base tags appear "naked" in the Contact header field - they have neither a "+" nor a "sip." prefix. All other tags will always have a leading "+" when present in the Contact header field, and will additionally have a "sip." if the tag is in the SIP tree.

接触述語は、用語の組み合わせです。各用語は、単一の特徴タグの制約を示し、各用語は、コンタクトヘッダフィールドに存在する別個の特徴パラメータで表現されます。このパラメータの構文は、フィーチャータグに依存します。特徴タグにおける各スラッシュは、単一引用符に変換され、そして各結腸を感嘆符に変換されます。ベースタグに - つまり、本明細書（sip.audio、sip.automata、sip.class、sip.duplex、sip.data、sip.control、sip.mobility、sip.description、SIPに記載のもの特徴タグ。イベント、sip.priority、sip.methods、sip.extensions、sip.schemes、sip.application、sip.video、言語、タイプ、sip.isfocus、sip.actorとsip.text）、先頭の "一口。"、存在する場合、削除されます。フィーチャータグのないこのリスト、大手の「一口。」存在する場合取り除いてはならない、と確かに、プラス記号（「+」）Contactヘッダーフィールドパラメータの最初の文字として追加する必要があります。その結果、特徴パラメータの名前です。これらのルールの結果、ベースタグは、Contactヘッダーフィールドに「裸」が表示される - 彼らはどちらも「+」も持っている「一口。」接頭辞。他のすべてのタグは常に持っています先頭の「+」ときContactヘッダーフィールドに存在し、さらに必要があります「一口。」タグは、SIPツリーにある場合。

The value of the feature parameter depends on the term of the conjunction. If the term is a boolean expression with a value of true, i.e., (sip.audio=TRUE), the contact parameter has no value. If the term of the conjunction is a disjunction, the value of the contact parameter is a quoted string. The quoted string is a comma separated list of strings, each one derived from one of the terms in the disjunction. If the term of the conjunction is a negation, the value of the contact parameter is a quoted string. The quoted string begins with an exclamation point (!), and the remainder is constructed from the expression being negated.

特徴パラメータの値は、連携の期間に依存します。この用語は、真の値を持つブール式である場合、すなわち、（sip.audio = TRUE）、コンタクトパラメータは値を持ちません。接続詞の用語は論理和である場合には、接触パラメータの値は引用符で囲まれた文字列です。引用符で囲まれた文字列は、文字列のカンマ区切りリスト、論理和のいずれかの用語に由来し、それぞれ1です。接続詞の用語が否定された場合は、接触パラメータの値は引用符で囲まれた文字列です。引用符で囲まれた文字列は、感嘆符（！）で始まり、残りは否定されている式から構成されています。

The remaining operation is to compute a string from a primitive filter. If the filter is a simple filter that is performing a numeric comparison, the string starts with an octothorpe (#), followed by the comparator in the filter (=, >=, or <=), followed by the value from the filter. If the value from the filter is expressed in rational form (X / Y), then X and Y are divided, yielding a decimal number, and this decimal number is output to the string.

残りの操作は、プリミティブフィルタから文字列を計算することです。フィルタは、数値比較を行っている単純なフィルタである場合、文字列はフィルタのコンパレータ続いて、シャープ（＃）で始まり（=、> =、または<=）、フィルタからの値が続きます。フィルタからの値は有理形（X / Y）で表される場合、XおよびYは、小数を得、分割され、この進数文字列に出力されます。

RFC 2533 uses a fractional notation to describe rational numbers. This specification uses a decimal form. The above text merely converts between the two representations. Practically speaking, this conversion is not needed since the numbers are the same in either case. However, it is described in case implementations wish to directly plug the predicates generated by the rules in this section into an RFC 2533 implementation.

RFC 2533には、合理的な数字を記述するために小数表記法を使用しています。この仕様は、小数点形式を使用しています。上記テキストは、単に2つの表現の間で変換します。数値はいずれの場合も同じであるため事実上、この変換は必要ありません。しかし、実装が直接RFC 2533の実装には、このセクションのルールによって生成された述語を接続したい場合に記載されています。

If the filter is a range (foo=X..Y), the string is equal to X:Y, where X and Y have been converted from fractional numbers (A / B) to their decimal equivalent.

Y、X及びYは、それらの10進数に分数（A / B）から変換された：フィルタ範囲（FOO = X..Y）である場合、文字列がXに等しいです。

If the filter is an equality over a token or boolean, then that token or boolean value ("TRUE" or "FALSE") is output to the string.

フィルタがトークンまたはブール上等価である場合、そのトークンまたはブール値（「true」または「false」）の文字列に出力されます。

If the filter is an equality over a quoted string, the output is a less than (<), followed by the quoted string, followed by a greater than (>).

フィルタは、引用符で囲まれた文字列上等価である場合、出力はより少ない（<）よりもより大きくすることにより、引用符で囲まれた文字列に続いて、続いて（>）。

As an example, this feature predicate:

例として、この機能の述語：

(& (sip.mobility=fixed) (| (! (sip.events=presence)) (sip.events=message-summary)) (| (language=en) (language=de)) (sip.description="PC") (sip.newparam=TRUE) (rangeparam=-4..5125/1000))

（＆（sip.mobility =固定）（|（（sip.events =存在））（sip.events =メッセージ要約））（|！（言語= EN）（言語=デ））（sip.description =」 PC "）（sip.newparam = TRUE）（rangeparam = -4..5125 / 1000））

would be converted into the following feature parameters:

以下の特徴パラメータに変換されます：

mobility="fixed";events="!presence,message-summary";language="en,de" ;description="<PC>";+sip.newparam;+rangeparam="#-4:+5.125"

"！プレゼンス、メッセージサマリ";モビリティ= "固定" イベント=;言語= "EN、デ";説明= "<PC>"; + sip.newparam; + rangeparam = "＃ - 4：5.125"

These feature tags would then appear as part of the Contact header field:

これらの機能タグは、Contactヘッダーフィールドの一部として表示されます：

Contact: <sip:user@pc.example.com> ;mobility="fixed";events="!presence,message-summary" ;language="en,de";description="<PC>" ;+sip.newparam;+rangeparam="#-4:+5.125"

連絡先：<SIP：user@pc.example.com>;モビリティ= "固定";イベント=;言語= "EN、デ";説明= "<PC>"; +一口 "プレゼンス、メッセージサマリ！"。 newparam; + rangeparam = "＃ - 4：5.125"

Notice how the leading "sip." was stripped from the sip.mobility, sip.events and sip.description feature tags before encoding them in the Contact header field. This is because these feature tags are amongst the base tags listed above. It is for this reason that these feature tags were not encoded with a leading "+" either. However, the sip.newparam feature tag was encoded with both the "+" and its leading "sip.", and the rangeparam was also encoded with a leading "+". This is because neither of these feature tags are defined in this specification. As such, the leading "sip." is not stripped off, and a "+" is added.

どの大手「一口。」に注目してくださいContactヘッダーフィールドでそれらを符号化する前にsip.mobility、sip.eventsとsip.description機能タグから剥離しました。これらの機能タグはベースタグの中で、上に列挙されているためです。これは、これらの機能のタグが先頭の「+」のいずれかでエンコードされていなかったのはこのためです。しかし、sip.newparam特徴タグ「SIP」「+」とその前の両方で符号化し、そしてrangeparamも先頭の「+」と符号化されました。これらの機能タグのどちらもこの仕様で定義されているためです。このよう、先頭の「一口。」として、剥ぎ取られていない、と「+」が追加されます。

6. Expressing Capabilities in a Registration

6.登録で機能を表現

When a UA registers, it can choose to indicate a feature set associated with a registered contact. Whether or not a UA does so depends on what the registered URI represents. If the registered URI represents a UA instance (the common case in registrations), a UA compliant to this specification SHOULD indicate a feature set using the mechanisms described here. If, however, the registered URI represents an address-of-record, or some other resource that is not representable by a single feature set, it SHOULD NOT include a feature set. As an example, if a user wishes to forward calls from sip:user1@example.com to sip:user2@example.org, it could generate a registration that looks like, in part:

UAが登録すると、それは、登録連絡先に関連した機能セットを示すために選択することができます。 UAかどうかは、その登録されたURIが何を表すかに依存しません。登録されたURIは、UAインスタンス（登録における一般的な場合）を表す場合、本明細書にUAの対応は、ここで説明されたメカニズムを使用して、機能セットを示すべきです。しかし、登録されたURIは、アドレスのレコード、または単一機能セットで表現されていないいくつかの他のリソースを表す場合、それは機能セットを含めるべきではありません。ユーザーは一口からのコールを転送したい場合の例としては、：user1@example.comは、SIPする：user2@example.orgを、それは一部には、のように見えるの登録を生成することがありました：

In this case, the registered contact is not identifying a UA, but rather, another address-of-record. In such a case, the registered contact would not indicate a feature set.

この場合、登録接触は、むしろ別のアドレス・オブ・レコードをUAを識別ではなく、。そのような場合には、登録した連絡先は、機能セットを示しません。

However, in some cases, a UA may wish to express feature parameters for an address-of-record. One example is an AOR which represents a multiplicity of devices in a home network, and routes to a proxy server in the user's home. Since all devices in the home are for personal use, the AOR itself can be described with the ;class="personal" feature parameter. A registration that forwards calls to this home AOR could make use of that feature parameter. Generally speaking, a feature parameter can only be associated with an address-of-record if all devices bound to that address-of-record share the exact same set of values for that feature parameter.

しかし、いくつかのケースでは、UAは、アドレス・オブ・レコードの特徴パラメータを表現することを望むかもしれません。一つの例は、ホームネットワーク内のデバイス、およびユーザのホームでのプロキシサーバーへのルートの多重度を表しAORです。クラス=「個人」の特徴パラメータ、家庭内のすべてのデバイスは、個人使用のためのものですので、AOR自体はして説明することができます。このホームAORに通話を転送登録がその特徴パラメータを利用することができます。すべてのデバイスは、そのアドレスのレコード共有にその特徴パラメータの値の正確な同じセットをバインド場合は一般的に言って、特徴パラメータは、アドレスのレコードに関連付けることができます。

Similarly, in some cases, a UA can exhibit one characteristic or another, but the characteristic is not known in advance. For example, a UA could represent a device that is a phone with an embedded answering machine. The ideal way to treat such devices is to model them as if they were actually a proxy fronting two devices - a phone (which is never an answering machine), and an answering machine (which is never a phone). The registration from this device would be constructed as if it were an AOR, as per the procedures above. Generally, this means that, unless the characteristic is identical between the logical devices, that characteristic will not be present in any registration generated by the actual device.

同様に、いくつかのケースでは、UAは、一つの特性または別を示すことができるが、特性が事前に知られていません。例えば、UAは、埋め込まれた留守番電話との電話であるデバイスを表すことができます。（留守番電話になることはありません）電話、および（電話ことはありません）留守番 - このようなデバイスを治療するための理想的な方法は、彼らは、実際には2つのデバイスに面しプロキシであるかのようにそれらをモデル化することです。それはAORであるかのように、このデバイスからの登録は、上記の手順に従って、構築されることになります。一般に、この特性は、論理デバイス間で同一である場合を除き、その特性は、実際のデバイスによって生成された登録中に存在しない、ということを意味します。

The remainder of this section assumes that a UA would like to associate a feature set with a contact that it is registering. This feature set is constructed and converted to a series of Contact header field parameters, as described in Section 5, and those feature parameters are added to the Contact header field value containing the URI to which the parameters apply. The Allow, Accept, Accept-Language and Allow-Events [9] header fields are allowed in REGISTER requests, and also indicate capabilities. However, their semantic in REGISTER is different, indicating capabilities, used by the registrar, for generation of the response. As such, they are not a substitute or an alternate for the Contact feature parameters, which indicate the capabilities of the UA generally speaking.

このセクションの残りの部分は、UAは、それが登録された連絡先と機能セットを関連付けしたいことを想定しています。この機能セットを構築し、第5節で説明したように、Contactヘッダフィールドパラメータの系列に変換し、そしてそれらの特徴パラメータは、パラメータが適用されるURIを含むContactヘッダフィールド値に加算されます。、許可受け入れ、言語を受け入れて、[9]ヘッダーフィールドはREGISTERリクエストで許可し、また能力を示すれる事象許可します。しかし、REGISTERにおけるそれらの意味論的応答を生成するために、レジストラが使用する能力を示す、異なっています。そのため、彼らは、UAの機能は一般的に示している連絡先の特徴パラメータ、の代用または代替ではありません。

The REGISTER request MAY contain a Require header field with the value "pref" if the client wants to be sure that the registrar understands the extensions defined in this specification. This means that the registrar will store the feature parameters, and make them available to elements accessing the location service within the domain. In the absence of the Require header field, a registrar that does not understand this extension will simply ignore the Contact header field parameters.

クライアントはレジストラはこの仕様で定義された拡張を理解していることを確認してくださいしたい場合REGISTERリクエストは、値「県」とRequireヘッダーフィールドを含むかもしれません。これは、レジストラが特徴パラメータを格納し、ドメイン内のロケーションサービスにアクセスする要素にそれらを利用できるようになることを意味します。 Requireヘッダーフィールドがない場合には、この拡張を理解していないレジストラは、単にContactヘッダーフィールドパラメータを無視します。

If a UA registers against multiple separate addresses-of-record, and the contacts registered for each have different capabilities, a UA MUST use different URIs in each registration. This allows the UA to uniquely determine the feature set that is associated with the request URI of an incoming request.

UAは、複数の別々のアドレス・オブ・レコードに対して登録し、それぞれに対して登録連絡先が異なる機能を持っている場合、UAは、各登録に異なるURIを使用しなければなりません。これは、UAが一意に着信要求の要求URIに関連付けられている機能セットを決定することを可能にします。

As an example, a voicemail server that is a UA that supports audio and video media types and is not mobile would construct a feature predicate like this:

例として、オーディオとビデオのメディアタイプをサポートし、携帯電話ではありませんUAあるボイスメールサーバは、このような機能の述語を構築します。

(& (sip.audio=TRUE) (sip.video=TRUE) (sip.actor=msg-taker) (sip.automata=TRUE) (sip.mobility=fixed) (| (sip.methods=INVITE) (sip.methods=BYE) (sip.methods=OPTIONS) (sip.methods=ACK) (sip.methods=CANCEL)))

（＆（sip.audio = TRUE）（sip.video = TRUE）（sip.actor = MSG採取）（sip.automata = TRUE）（sip.mobility =固定）（|（sip.methodsの=はINVITE）（SIP .methods = BYE）（sip.methodsの=オプション）（sip.methods = ACK）（sip.methodsの=はCANCEL）））

These would be converted into feature parameters and included in the REGISTER request:

これらは、特徴パラメータに変換し、REGISTERリクエストに含まれます：

REGISTER sip:example.com SIP/2.0 From: sip:user@example.com;tag=asd98 To: sip:user@example.com Call-ID: hh89as0d-asd88jkk@host.example.com CSeq: 9987 REGISTER Max-Forwards: 70 Via: SIP/2.0/UDP host.example.com;branch=z9hG4bKnashds8 Contact: <sip:user@host.example.com>;audio;video ;actor="msg-taker";automata;mobility="fixed" ;methods="INVITE,BYE,OPTIONS,ACK,CANCEL" Content-Length: 0

SIP：user@example.comコールID：hh89as0d-asd88jkk@host.example.comのCSeq：9987 REGISTER MAX-、example.com SIP / 2.0：：：SIPタグ= asd98にuser@example.com SIPレジスタフォワード：70経由：SIP / 2.0 / UDP host.example.com;ブランチ= z9hG4bKnashds8連絡先：<SIP：user@host.example.com>;オーディオ;ビデオ;俳優= "MSG-係";オートマトン;モビリティ=」固定」;方法は= "INVITE、BYE、OPTIONSは、ACKは、" CANCELのContent-Length：0

Note that a voicemail server is usually an automata and a message taker.

ボイスメールサーバは通常、オートマトンとメッセージ受け手であることに注意してください。

When a UAC refreshes its registration, it MUST include its feature parameters in that refresh if it wishes for them to remain active. Furthermore, when a registrar returns a 200 OK response to a REGISTER request, each Contact header field value MUST include all of the feature parameters associated with that URI.

UACは、その登録をリフレッシュすると、それらがアクティブのまますることが希望する場合、それはそのリフレッシュにその特徴パラメータを含まなければなりません。レジストラは、REGISTERリクエストに対する200 OK応答を返すとさらに、各Contactヘッダーフィールド値は、そのURIに関連付けられた特徴パラメータの全てを含まなければなりません。

7. Indicating Feature Sets in Remote Target URIs

リモートターゲットのURI 7.表す特徴セット

Target refresh requests and responses are used to establish and modify the remote target URI in a dialog. The remote target URI is conveyed in the Contact header field. A UAC or UAS MAY add feature parameters to the Contact header field value in target refresh requests and responses for the purpose of indicating the capabilities of the UA. To do that, it constructs a set of feature parameters according to Section 5. These are then added as Contact header field parameters in the request or response.

ターゲットリフレッシュ要求と応答を確立し、ダイアログでリモートターゲットURIを変更するために使用されています。リモートターゲットURIは、コンタクトヘッダフィールドに搬送されます。 UACまたはUASは、UAの能力を示すことを目的のターゲットリフレッシュ要求と応答におけるContactヘッダーフィールド値に特徴パラメータを追加するかもしれません。これを行うには、それは、これらは、その後、要求または応答におけるContactヘッダーフィールドのパラメータとして追加されているセクション5に係る特徴パラメータのセットを構築します。

The feature parameters can be included in both initial requests and mid-dialog requests, and MAY change mid-dialog to signal a change in UA capabilities.

特徴パラメータは、最初のリクエストと、ダイアログ中のリクエストの両方に含めることができ、かつUA能力の変化を通知するために半ばダイアログを変更することがあります。

There is overlap in the callee capabilities mechanism with the Allow, Accept, Accept-Language, and Allow-Events [9] header fields, which can also be used in target refresh requests. Specifically, the Allow header field and "sip.methods" feature tag indicate the same information. The Accept header field and the "type" feature tag indicate the same information. The Accept-Language header field and the "language" feature tag indicate the same information. The Allow-Events header field and the "sip.events" feature tag indicate the same information. It is possible that other header fields and feature tags defined in the future may also overlap. When there exists a feature tag that describes a capability that can also be represented with a SIP header field, a UA MUST use the header field to describe the capability. A UA receiving a message that contains both the header field and the feature tag MUST use the header field, and not the feature tag.

オーバーラップは、許可受け入れ、言語を受け入れ、ターゲットリフレッシュ要求にも使用することができる[9]のヘッダフィールド、事象を許可するとともに着信機能機構です。具体的には、許可ヘッダフィールドと「sip.methods」機能タグは、同じ情報を示します。 Acceptヘッダーフィールドと「タイプ」機能タグと同じ情報を示します。 Accept-Languageヘッダーフィールドと「言語」機能タグは、同じ情報を示します。許可-イベントヘッダーフィールドと「sip.events」機能タグは、同じ情報を示します。将来に定義されている他のヘッダフィールドと特徴タグも重なることが可能です。また、SIPヘッダフィールドで表すことができる能力を記述する特徴タグが存在する場合、UAは、能力を記述するためにヘッダーフィールドを使用しなければなりません。 UAは、ヘッダフィールドと、ヘッダ・フィールドを使用しなければならない特徴タグはなく、特徴タグの両方を含むメッセージを受信します。

8. OPTIONS Processing

8.オプションの処理

When a UAS compliant to this specification receives an OPTIONS request, it MAY add feature parameters to the Contact header field in the OPTIONS response for the purpose of indicating the capabilities of the UA. To do that, it constructs a set of feature parameters according to Section 5. These are then added as Contact header field parameters in OPTIONS response. Indeed, if feature parameters were included in the registration generated by that UA, those same parameters SHOULD be used in the OPTIONS response.

この仕様に準拠するUASは、OPTIONS要求を受信すると、UAの能力を示す目的のためOPTIONS応答のContactヘッダフィールドに特徴パラメータを加えるかもしれ。これを行うには、それは、これらはその後、OPTIONS応答におけるContactヘッダーフィールドのパラメータとして追加されているセクション5に係る特徴パラメータのセットを構築します。特徴パラメータがそのUAによって生成された登録に含まれていたならば実際、これらの同じパラメータは、OPTIONS応答で使用されるべきです。

The guidelines in Section 7 regarding the overlap of the various callee capabilities feature tags with SIP header fields applies to the generation of OPTIONS responses as well. In particular, they apply when a Contact header field is describing the UA which generated the OPTIONS response. When a Contact header field in the OPTIONS response is identifying a different UA, there is no overlap.

種々の着信機能のオーバーラップに関する第7のガイドラインは、SIPヘッダフィールドを持つタグを備えてもOPTIONS応答の生成に適用されます。特に、それらは、ContactヘッダフィールドはOPTIONS応答を生成したUAを記載されているときに適用されます。 OPTIONS応答のContactヘッダフィールドは異なるUAを識別されたときに、重なりません。

9. Contact Header Field

9.連絡先ヘッダーフィールド

This specification extends the Contact header field. In particular, it allows for the Contact header field parameters to include feature-param. Feature-param is a feature parameter that describes a feature of the UA associated with the URI in the Contact header field. Feature parameters are identifiable because they either belong to the well known set of base feature tags, or they begin with a plus sign.

この仕様は、Contactヘッダーフィールドを拡張します。特に、特徴PARAMを含むようにコンタクトヘッダフィールドパラメータを可能にします。フィーチャー-paramがContactヘッダーフィールドにURIに関連付けられたUAの機能について説明した特徴パラメータです。彼らはベースフィーチャータグのよく知られたセットに属しているか、彼らはプラス記号で始まるため、特徴パラメータが特定可能です。

feature-param = enc-feature-tag [EQUAL LDQUOT (tag-value-list / string-value ) RDQUOT] enc-feature-tag = base-tags / other-tags base-tags = "audio" / "automata" / "class" / "duplex" / "data" / "control" / "mobility" / "description" / "events" / "priority" / "methods" / "schemes" / "application" / "video" / "language" / "type" / "isfocus" / "actor" / "text" / "extensions" other-tags = "+" ftag-name ftag-name = ALPHA *( ALPHA / DIGIT / "!" / "'" / "." / "-" / "%" )

特徴PARAM = ENC-特徴タグ[EQUAL LDQUOT（タグ値リスト/文字列値）RDQUOT] ENC-特徴タグ=ベースタグ/他のタグベースタグ= "オーディオ" / "オートマトン" / 「クラス」/「両面」/「データ」/「コントロール」/「移動度」/「説明」/「イベント」/「優先」/「メソッド」/「スキーム」/「アプリケーション」/「ビデオ」/「言語"/ "タイプ"/ "isfocus"/ "俳優"/ "文字"/ "拡張" 他のタグ= "+" FTAG名FTAG名= ALPHA *（ALPHA / DIGIT / "！"/ "'"/ "" / " - " / "％"）

tag-value-list = tag-value *("," tag-value) tag-value = ["!"] (token-nobang / boolean / numeric) token-nobang = 1*(alphanum / "-" / "." / "%" / "*" / "_" / "+" / "`" / "'" / "~" ) boolean = "TRUE" / "FALSE" numeric = "#" numeric-relation number numeric-relation = ">=" / "<=" / "=" / (number ":") number = [ "+" / "-" ] 1*DIGIT ["." 0*DIGIT] string-value = "<" *(qdtext-no-abkt / quoted-pair ) ">" qdtext-no-abkt = LWS / %x21 / %x23-3B / %x3D / %x3F-5B / %x5D-7E / UTF8-NONASCII

タグ値リスト=タグ値*（ "" タグ値）タグ値= [ "！"]（トークンnobang /ブール/数字）トークンnobang = 1 *（alphanum / " - " / " 。」/ "％" / "*" / "_" / "+" / "`"/ "'"/ "〜"）ブール= "TRUE"/ "FALSE" 数値= "＃" 数値関係数の数値-relation = "> =" / "<=" / "=" /（番号 "："）数= [ "+" / " - "] 1 * DIGITの[ "" 0 * DIGIT]文字列値= "<" *（qdtext-NO-abkt /引用対） ">" qdtext-NO-abkt = LWS /％X21 /％x23-3B /％X3D /％からx3F-5B / ％x5D-7E / UTF8-NONASCII

Note that the tag-value-list uses an actual comma instead of the COMMA construction because it appears within a quoted string, where line folding cannot take place.

それはライン折りたたみが起こらないことができ引用符で囲まれた文字列内に表示されますので、タグ値リストはCOMMA構築するのではなく、実際のカンマを使用することに注意してください。

The production for qdtext can be found in RFC 3261 [1].

qdtextの製造は、RFC 3261に見出すことができる[1]。

There are additional constraints on the usage of feature-param that cannot be represented in a BNF. There MUST only be one instance of any feature tag in feature-param. Any numbers present in a feature parameter MUST be representable using an ANSI C double.

BNFで表現できない機能-PARAMの使用に関する追加の制約があります。唯一の機能-のparamで任意の特徴タグの1つのインスタンスがあるに違いありません。特徴パラメータに存在する任意の数字は、ANSI Cのdoubleを使って表現でなければなりません。

The following production updates the one in RFC 3261 [1] for contact-params:

以下の製造は、接触paramsは[1] RFC 3261の一方を更新します。

contact-params = c-p-q / c-p-expires / feature-param / contact-extension

接触paramsは= C-P-Q / C-P-満了する/特徴PARAM /接触拡張

10. Media Feature Tag Definitions

10.メディアフィーチャータグの定義

This specification defines an initial set of media feature tags for use with this specification. This section serves as the IANA registration for these feature tags, which are made into the SIP media feature tag tree. New media feature tags are registered in the IETF or global trees based on the process defined for feature tag registrations [3], or in the SIP tree based on the process defined in Section 12.1.

この仕様は、この仕様で使用するためのメディア特徴タグの初期セットを定義します。このセクションでは、SIPメディア特徴タグツリーに作られているこれらの特徴タグのためのIANA登録として機能します。新しいメディア特徴タグは、[3]、または12.1項で定義されたプロセスに基づいてSIPツリーでフィーチャータグの登録のために定義されたプロセスに基づいて、IETFまたはグローバルツリーに登録されています。

Any registered feature tags MAY be used with this specification. However, several existing ones appear to be particularly applicable. These include the language feature tag [6], which can be used to specify the language of the human or automata represented by the UA, and the type feature tag [7], which can be used to specify the MIME types that a SIP UA can receive in a SIP message. The audio, video, application, data, and control feature tags in the SIP tree (each of which indicate a media type, as defined in RFC 2327 [8]) are different. They do not indicate top level MIME types which can be received in SIP requests. Rather, they indicate media types that can be used in media streams, and as a result, match up with the types defined in RFC 2327 [8].

任意の登録特徴タグは、この仕様で使用されるかもしれません。しかし、いくつかの既存のものは特に適用可能であると思われます。これらは、言語機能タグを含む[6]、UAで表されるヒトまたはオートマトンの言語、及び型特徴タグを指定するために使用することができる[7]、SIP UA MIMEタイプを指定するために使用することができますSIPメッセージで受け取ることができます。（RFC 2327で定義されているメディアタイプを示すそれぞれが、[8]）SIPツリー内のオーディオ、ビデオ、アプリケーション、データ、および制御機能タグは異なっています。彼らは、SIPリクエストで受信することができ、トップレベルのMIMEタイプを示すものではありません。むしろ、それらは、メディアストリームに使用することができるメディアタイプを示し、その結果として、[8] RFC 2327で定義されたタイプと一致します。

If a new SDP media type were to be defined, such as "message", a new feature tag registration SHOULD be created for it in the SIP tree. The name of the feature tag MUST equal "sip." concatenated with the name of the media type, unless there is an unlikely naming collision between the new media type and an existing feature tag registration. As a result, implementations can safely construct caller preferences and callee capabilities for the new media type before it is registered, as long as there is no naming conflict.

新しいSDPのメディアタイプは、このような「メッセージ」として、定義されるとしたら、新機能のタグ登録は、SIPツリーにそれのために作成する必要があります。フィーチャータグの名前は、「SIP」を等しくなければなりません新しいメディアタイプと既存のフィーチャータグの登録の間にそう命名衝突がない限り、メディアタイプの名前と連結。それは限り何の名前の競合が存在しないとして、登録される前に、その結果、実装が安全に新しいメディアタイプのために、発信者の嗜好と呼び出し先の能力を構築することができます。

If a new media feature tag is registered with the intent of using that tag with this specification, the registration is done for the unencoded form of the tag (see Section 5). In other words, if a new feature tag "foo" is registered in the IETF tree, the IANA registration would be for the tag "foo" and not "+foo". Similarly, if a new feature tag "sip.gruu" is registered in the SIP tree, the IANA registration would be for the tag "sip.gruu" and not "+sip.gruu" or "gruu". As such, all registrations into the SIP tree will have the "sip." prefix.

新しいメディア特徴タグはこの仕様でそのタグを使用しての意図に登録されている場合は、登録はタグのエンコードされていない形式のために行われている（第5節参照）。新機能タグ「fooが」IETF木に登録されている場合は、他の言葉では、IANA登録はタグ「foo」とはない「+ foo」というのためになります。新機能タグ「sip.gruuは、」SIPツリーに登録されている場合も同様に、IANA登録はタグ「sip.gruu」ではなく「+ sip.gruu」または「GRUU」のためになります。そのため、SIPツリーにすべての登録は、「SIP」を持っています接頭辞。

The feature tags in this section are all registered in the SIP media feature tag tree created by Section 12.1.

このセクションの機能タグは、すべてのセクション12.1で作成されたSIPメディア特徴タグツリーに登録されています。

10.1. Audio

10.1. オーディオ

Media feature tag name: sip.audio

メディアフィーチャータグ名：sip.audio

ASN.1 Identifier: 1.3.6.1.8.4.1

ASN.1識別子：1.3.6.1.8.4.1

Summary of the media feature indicated by this tag: This feature tag indicates that the device supports audio as a streaming media type.

このタグで示されるメディアフィーチャーの概要：このフィーチャータグは、デバイスがストリーミングメディアタイプとしてオーディオサポートしていることを示しています。

Values appropriate for use with this feature tag: Boolean.

ブール：この機能タグで使用するための適切な値。

The feature tag is intended primarily for use in the following applications, protocols, services, or negotiation mechanisms: This feature tag is most useful in a communications application for describing the capabilities of a device, such as a phone or PDA.

フィーチャータグは、主に以下のアプリケーション、プロトコル、サービス、または交渉メカニズムにおける使用のために意図されています。この機能タグは、このような携帯電話やPDAなどのデバイスの機能を記述するための通信アプリケーションに最も有用です。

Examples of typical use: Routing a call to a phone that can support audio.

典型的な使用例：オーディオをサポートすることができます携帯電話に通話をルーティング。

Related standards or documents: RFC 3840

関連する規格または文書：RFC 3840

Security Considerations: Security considerations for this media feature tag are discussed in Section 11.1 of RFC 3840.

セキュリティの考慮：このメディアフィーチャータグに関するセキュリティの考慮事項は、RFC 3840のセクション11.1で議論されています。

10.2. Application

10.2. 応用

Media feature tag name: sip.application

メディアフィーチャータグ名：sip.application

ASN.1 Identifier: 1.3.6.1.8.4.2

ASN.1識別子：1.3.6.1.8.4.2

Summary of the media feature indicated by this tag: This feature tag indicates that the device supports application as a streaming media type. This feature tag exists primarily for completeness. Since so many MIME types are underneath application, indicating the ability to support applications provides little useful information.

このタグで示されるメディアフィーチャーの概要：このフィーチャータグは、デバイスがストリーミングメディアタイプとしてアプリケーションをサポートしていることを示しています。この機能タグは主に、完全性のために存在します。非常に多くのMIMEタイプは、アプリケーションの下にあるので、アプリケーションをサポートする能力を示すことはほとんど有用な情報を提供します。

Values appropriate for use with this feature tag: Boolean.

ブール：この機能タグで使用するための適切な値。

The feature tag is intended primarily for use in the following applications, protocols, services, or negotiation mechanisms: This feature tag is most useful in a communications application, for describing the capabilities of a device, such as a phone or PDA.

フィーチャータグは、主に以下のアプリケーション、プロトコル、サービス、または交渉メカニズムにおける使用のために意図されています。この機能タグは、このような携帯電話やPDAなどのデバイスの機能を記述するために、通信アプリケーションに最も有用です。

Examples of typical use: Routing a call to a phone that can support a media control application.

典型的な使用例：メディア制御アプリケーションをサポートすることができます携帯電話に通話をルーティング。

Related standards or documents: RFC 3840

関連する規格または文書：RFC 3840

Security Considerations: Security considerations for this media feature tag are discussed in Section 11.1 of RFC 3840.

セキュリティの考慮：このメディアフィーチャータグに関するセキュリティの考慮事項は、RFC 3840のセクション11.1で議論されています。

10.3. Data

10.3. データ

Media feature tag name: sip.data

メディアフィーチャータグ名：sip.data

ASN.1 Identifier: 1.3.6.1.8.4.3

ASN.1識別子：1.3.6.1.8.4.3

Summary of the media feature indicated by this tag: This feature tag indicates that the device supports data as a streaming media type.

このタグで示されるメディアフィーチャーの概要：このフィーチャータグは、デバイスがストリーミングメディアタイプとしてデータをサポートしていることを示しています。

Values appropriate for use with this feature tag: Boolean.

ブール：この機能タグで使用するための適切な値。

Examples of typical use: Routing a call to a phone that can support a data streaming application.

典型的な使用例：データ・ストリーミング・アプリケーションをサポートすることができます携帯電話に通話をルーティング。

Related standards or documents: RFC 3840

関連する規格または文書：RFC 3840

Security Considerations: Security considerations for this media feature tag are discussed in Section 11.1 of RFC 3840.

セキュリティの考慮：このメディアフィーチャータグに関するセキュリティの考慮事項は、RFC 3840のセクション11.1で議論されています。

10.4. Control

10.4. コントロール

Media feature tag name: sip.control

メディアフィーチャータグ名：sip.control

ASN.1 Identifier: 1.3.6.1.8.4.4

ASN.1識別子：1.3.6.1.8.4.4

Summary of the media feature indicated by this tag: This feature tag indicates that the device supports control as a streaming media type.

このタグで示されるメディアフィーチャーの概要：このフィーチャータグは、デバイスがストリーミングメディアタイプとしてコントロールをサポートしていることを示しています。

Values appropriate for use with this feature tag: Boolean.

ブール：この機能タグで使用するための適切な値。

Examples of typical use: Routing a call to a phone that can support a floor control application.

典型的な使用例：フロア制御アプリケーションをサポートすることができます携帯電話に通話をルーティング。

Related standards or documents: RFC 3840

関連する規格または文書：RFC 3840

Security Considerations: Security considerations for this media feature tag are discussed in Section 11.1 of RFC 3840.

セキュリティの考慮：このメディアフィーチャータグに関するセキュリティの考慮事項は、RFC 3840のセクション11.1で議論されています。

10.5. Video

10.5. ビデオ

Media feature tag name: sip.video

メディアフィーチャータグ名：sip.video

ASN.1 Identifier: 1.3.6.1.8.4.5

ASN.1識別子：1.3.6.1.8.4.5

Summary of the media feature indicated by this tag: This feature tag indicates that the device supports video as a streaming media type.

このタグで示されるメディアフィーチャーの概要：このフィーチャータグは、デバイスがストリーミングメディアタイプとしてビデオをサポートしていることを示しています。

Values appropriate for use with this feature tag: Boolean.

ブール：この機能タグで使用するための適切な値。

Examples of typical use: Routing a call to a phone that can support video.

典型的な使用例：ビデオをサポートすることができます携帯電話に通話をルーティング。

Related standards or documents: RFC 3840

関連する規格または文書：RFC 3840

Security Considerations: Security considerations for this media feature tag are discussed in Section 11.1 of RFC 3840.

セキュリティの考慮：このメディアフィーチャータグに関するセキュリティの考慮事項は、RFC 3840のセクション11.1で議論されています。

10.6. Text

10.6. テキスト

Media feature tag name: sip.text

メディアフィーチャータグ名：sip.text

ASN.1 Identifier: 1.3.6.1.8.4.6

ASN.1識別子：1.3.6.1.8.4.6

Summary of the media feature indicated by this tag: This feature tag indicates that the device supports text as a streaming media type.

このタグで示されるメディアフィーチャーの概要：このフィーチャータグは、デバイスがストリーミングメディアタイプとしてテキストをサポートしていることを示しています。

Values appropriate for use with this feature tag: Boolean.

ブール：この機能タグで使用するための適切な値。

Examples of typical use: Routing a call to a phone that can support text.

典型的な使用例：テキストをサポートすることができます携帯電話に通話をルーティング。

Related standards or documents: RFC 3840

関連する規格または文書：RFC 3840

Security Considerations: Security considerations for this media feature tag are discussed in Section 11.1 of RFC 3840.

セキュリティの考慮：このメディアフィーチャータグに関するセキュリティの考慮事項は、RFC 3840のセクション11.1で議論されています。

10.7. Automata

10.7. オートマチック

Media feature tag name: sip.automata

メディアフィーチャータグ名：sip.automata

ASN.1 Identifier: 1.3.6.1.8.4.7

ASN.1識別子：1.3.6.1.8.4.7

Summary of the media feature indicated by this tag: The sip.automata feature tag is a boolean value that indicates whether the UA represents an automata (such as a voicemail server, conference server, IVR, or recording device) or a human.

このタグで示されるメディア機能の概要：sip.automata特徴タグは、UAは、（例えば、ボイスメールサーバ、会議サーバ、IVR、または記録装置など）オートマトンまたはヒトを表すかどうかを示すブール値です。

Values appropriate for use with this feature tag: Boolean. TRUE indicates that the UA represents an automata.

ブール：この機能タグで使用するための適切な値。 TRUEは、UAは、オートマトンを表すことを示しています。

Examples of typical use: Refusing to communicate with an automata when it is known that automated services are unacceptable.

典型的な使用例：自動化されたサービスが受け入れられないことが知られている場合オートマトンとの通信を拒否。

Related standards or documents: RFC 3840

関連する規格または文書：RFC 3840

Security Considerations: Security considerations for this media feature tag are discussed in Section 11.1 of RFC 3840.

セキュリティの考慮：このメディアフィーチャータグに関するセキュリティの考慮事項は、RFC 3840のセクション11.1で議論されています。

10.8. Class

10.8. クラス

Media feature tag name: sip.class

メディアフィーチャータグ名：sip.class

ASN.1 Identifier: 1.3.6.1.8.4.8

ASN.1識別子：1.3.6.1.8.4.8

Summary of the media feature indicated by this tag: This feature tag indicates the setting, business or personal, in which a communications device is used.

このタグで示されるメディア機能の概要：この機能タグは、通信デバイスが使用される、設定、ビジネスまたは個人を示します。

Values appropriate for use with this feature tag: Token with an equality relationship. Typical values include:

平等な関係を持つトークン：この機能タグで使用するための適切な値。典型的な値は次のとおりです。

business: The device is used for business communications.

ビジネス：デバイスがビジネスコミュニケーションのために使用されています。

personal: The device is used for personal communications.

個人：デバイスは、個人の通信に使用されます。

The feature tag is intended primarily for use in the following applications, protocols, services, or negotiation mechanisms: This feature tag is most useful in a communications application, for describing the capabilities of a device, such as a phone or PDA.

Examples of typical use: Choosing between a business phone and a home phone.

典型的な使用例：ビジネス電話と自宅の電話の間で選択します。

Related standards or documents: RFC 3840

関連する規格または文書：RFC 3840

Security Considerations: Security considerations for this media feature tag are discussed in Section 11.1 of RFC 3840.

セキュリティの考慮：このメディアフィーチャータグに関するセキュリティの考慮事項は、RFC 3840のセクション11.1で議論されています。

10.9. Duplex

10.9. デュープレックス

Media feature tag name: sip.duplex

メディアフィーチャータグ名：sip.duplex

ASN.1 Identifier: 1.3.6.1.8.4.9

ASN.1識別子：1.3.6.1.8.4.9

Summary of the media feature indicated by this tag: The sip.duplex media feature tag indicates whether a communications device can simultaneously send and receive media ("full"), alternate between sending and receiving ("half"), can only receive ("receive-only") or only send ("send-only").

このタグで示されるメディア機能の概要：sip.duplexメディア特徴タグは、通信デバイスが同時に（「完全」）メディアを送信および受信できるかどうかを示し、（「半分」）送受信間で交互にのみ受信することができます（」 -のみ受信「）のみ（送信」送信専用」）。

Values appropriate for use with this feature tag: Token with an equality relationship. Typical values include:

平等な関係を持つトークン：この機能タグで使用するための適切な値。典型的な値は次のとおりです。

full: The device can simultaneously send and receive media.

フル：デバイスが同時にメディアを送受信することができます。

half: The device can alternate between sending and receiving media.

ハーフ：デバイスがメディアの送受信を交互にすることができます。

receive-only: The device can only receive media.

受信専用：デバイスはメディアだけを受け取ることができます。

send-only: The device can only send media.

送信専用：デバイスはメディアのみを送信することができます。

Examples of typical use: Choosing to communicate with a broadcast server, as opposed to a regular phone, when making a call to hear an announcement.

典型的な使用例：発表を聞くために電話をかける際に、通常の電話とは反対に、放送サーバと通信するために選択します。

Related standards or documents: RFC 3840

関連する規格または文書：RFC 3840

Security Considerations: Security considerations for this media feature tag are discussed in Section 11.1 of RFC 3840.

セキュリティの考慮：このメディアフィーチャータグに関するセキュリティの考慮事項は、RFC 3840のセクション11.1で議論されています。

10.10. Mobility

10.10. 可動性

Media feature tag name: sip.mobility

メディアフィーチャータグ名：sip.mobility

ASN.1 Identifier: 1.3.6.1.8.4.10

ASN.1識別子：1.3.6.1.8.4.10

Summary of the media feature indicated by this tag: The sip.mobility feature tag indicates whether the device is fixed (meaning that it is associated with a fixed point of contact with the network), or mobile (meaning that it is not associated with a fixed point of contact). Note that cordless phones are fixed, not mobile, based on this definition.

このタグで示されるメディア機能の概要：sip.mobility特徴タグは、（それがネットワークとの接触の固定点に関連していることを意味する）装置が固定されているかどうかを示す、あるいはモバイル（それが関連付けられていないことを意味します接点の固定点）。この定義に基づいて、モバイルではない、コードレス電話が固定されていることに注意してください。

Values appropriate for use with this feature tag: Token with an equality relationship. Typical values include:

平等な関係を持つトークン：この機能タグで使用するための適切な値。典型的な値は次のとおりです。

fixed: The device is stationary.

固定：デバイスが静止しています。

mobile: The device can move around with the user.

モバイル：デバイスがユーザーに動き回ることができます。

Examples of typical use: Choosing to communicate with a wireless phone instead of a desktop phone.

典型的な使用例：代わりに、デスクトップフォンの携帯電話と通信するために選択します。

Related standards or documents: RFC 3840

関連する規格または文書：RFC 3840

Security Considerations: Security considerations for this media feature tag are discussed in Section 11.1 of RFC 3840.

セキュリティの考慮：このメディアフィーチャータグに関するセキュリティの考慮事項は、RFC 3840のセクション11.1で議論されています。

10.11. Description

10.11. 説明

Media feature tag name: sip.description

メディアフィーチャータグ名：sip.description

ASN.1 Identifier: 1.3.6.1.8.4.11

ASN.1識別子：1.3.6.1.8.4.11

Summary of the media feature indicated by this tag: The sip.description feature tag provides a textual description of the device.

このタグで示されるメディア機能の概要：sip.description特徴タグは、デバイスのテキスト記述を提供します。

Values appropriate for use with this feature tag: String with an equality relationship.

平等な関係を持つ文字列：この機能タグで使用するための適切な値。

Examples of typical use: Indicating that a device is of a certain make and model.

典型的な使用例：デバイスが特定の製造元とモデルであることを示します。

Related standards or documents: RFC 3840

関連する規格または文書：RFC 3840

Security Considerations: Security considerations for this media feature tag are discussed in Section 11.1 of RFC 3840.

セキュリティの考慮：このメディアフィーチャータグに関するセキュリティの考慮事項は、RFC 3840のセクション11.1で議論されています。

10.12. Event Packages

10.12. イベントパッケージ

Media feature tag name: sip.events

メディアフィーチャータグ名：sip.events

ASN.1 Identifier: 1.3.6.1.8.4.12

ASN.1識別子：1.3.6.1.8.4.12

Summary of the media feature indicated by this tag: Each value of the sip.events (note the plurality) feature tag indicates a SIP event package [9] supported by a SIP UA. The values for this tag equal the event package names that are registered by each event package.

このタグで示されるメディア機能の概要：sip.eventsの各値（複数を注意）機能タグがSIPイベントパッケージを示す[9] SIP UAによってサポートされます。このタグの値は、各イベントパッケージによって登録されたイベントパッケージ名に等しいです。

Values appropriate for use with this feature tag: Token with an equality relationship. Values are taken from the IANA SIP Event types namespace registry.

平等な関係を持つトークン：この機能タグで使用するための適切な値。値は、IANA SIPイベントタイプの名前空間のレジストリから取得されます。

Examples of typical use: Choosing to communicate with a server that supports the message waiting event package, such as a voicemail server [12].

典型的な使用例：このようボイスメールサーバとしてイベントパッケージ、[12]を待っているメッセージをサポートしているサーバーと通信するために選択します。

Related standards or documents: RFC 3840

関連する規格または文書：RFC 3840

Security Considerations: Security considerations for this media feature tag are discussed in Section 11.1 of RFC 3840.

セキュリティの考慮：このメディアフィーチャータグに関するセキュリティの考慮事項は、RFC 3840のセクション11.1で議論されています。

10.13. Priority

10.13. 優先

Media feature tag name: sip.priority

メディアフィーチャータグ名：sip.priority

ASN.1 Identifier: 1.3.6.1.8.4.13

ASN.1識別子：1.3.6.1.8.4.13

Summary of the media feature indicated by this tag: The sip.priority feature tag indicates the call priorities the device is willing to handle. A value of X means that the device is willing to take requests with priority X and higher. This does not imply that a phone has to reject calls of lower priority. As always, the decision on handling of such calls is a matter of local policy.

このタグで示されるメディアフィーチャーの概要：sip.priorityフィーチャータグは、デバイスが処理していく所存ですコールの優先順位を示します。 Xの値は、デバイスが優先X以降で要求を取って喜んでであることを意味します。これは、携帯電話は優先順位の低いコールを拒否しなければならないことを意味するものではありません。いつものように、このような呼び出しの取り扱いに関する決定は、ローカルポリシーの問題です。

Values appropriate for use with this feature tag: An integer. Each integral value corresponds to one of the possible values of the Priority header field as specified in SIP [1]. The mapping is defined as:

整数：この機能タグで使用するための適切な値。 SIP [1]で指定されるように各積分値は、優先度ヘッダーフィールドの可能な値の1つに対応します。マッピングは次のように定義されています。

non-urgent: Integral value of 10. The device supports non-urgent calls.

非緊急：10の積分値は、デバイスが非緊急の呼び出しをサポートしています。

normal: Integral value of 20. The device supports normal calls.

通常：20の積分値は、デバイスが通常の呼び出しをサポートしています。

urgent: Integral value of 30. The device supports urgent calls.

緊急：30の積分値は、デバイスが緊急コールをサポート。

emergency: Integral value of 40. The device supports calls in the case of an emergency situation.

緊急：40.デバイスの積分値は、緊急事態の場合の呼び出しをサポートしています。

Examples of typical use: Choosing to communicate with the emergency cell phone of a user.

典型的な使用例：ユーザーの緊急の携帯電話と通信するために選択します。

Related standards or documents: RFC 3840

関連する規格または文書：RFC 3840

Security Considerations: Security considerations for this media feature tag are discussed in Section 11.1 of RFC 3840.

セキュリティの考慮：このメディアフィーチャータグに関するセキュリティの考慮事項は、RFC 3840のセクション11.1で議論されています。

10.14. Methods

10.14. メソッド

Media feature tag name: sip.methods

メディアフィーチャータグ名：sip.methods

ASN.1 Identifier: 1.3.6.1.8.4.14

ASN.1識別子：1.3.6.1.8.4.14

Summary of the media feature indicated by this tag: Each value of the sip.methods (note the plurality) feature tag indicates a SIP method supported by this UA. In this case, "supported" means that the UA can receive requests with this method. In that sense, it has the same connotation as the Allow header field.

このタグで示されるメディア機能の概要：sip.methodsの各値（複数を注意）機能タグは、このUAによってサポートされるSIP方法を示しています。この場合、UAは、この方法でリクエストを受け取ることができることを意味し、「サポート」。その意味では、それが許可ヘッダフィールドと同じ意味合いを有しています。

Values appropriate for use with this feature tag: Token with an equality relationship. Values are taken from the Methods table defined in the IANA SIP parameters registry.

平等な関係を持つトークン：この機能タグで使用するための適切な値。値は、IANAのSIPパラメータをレジストリで定義されたメソッドの表から取得されます。

Examples of typical use: Choosing to communicate with a presence application on a PC, instead of a PC phone application.

典型的な使用例：代わりにPC用電話アプリケーションのPC上のプレゼンスアプリケーションと通信するために選択します。

Related standards or documents: RFC 3840

関連する規格または文書：RFC 3840

Security Considerations: Security considerations for this media feature tag are discussed in Section 11.1 of RFC 3840.

セキュリティの考慮：このメディアフィーチャータグに関するセキュリティの考慮事項は、RFC 3840のセクション11.1で議論されています。

10.15. Extensions

10.15. 拡張機能

Media feature tag name: sip.extensions

メディアフィーチャータグ名：sip.extensions

ASN.1 Identifier: 1.3.6.1.8.4.15

ASN.1識別子：1.3.6.1.8.4.15

Summary of the media feature indicated by this tag: Each value of the sip.extensions feature tag (note the plurality) is a SIP extension (each of which is defined by an option-tag registered with IANA) that is understood by the UA. Understood, in this context, means that the option tag would be included in a Supported header field in a request.

このタグで示されるメディア機能の概要：sip.extensionsの各値は、UAによって理解されているタグ（複数注意）（これらの各々はIANAに登録されたオプション・タグによって定義される）SIP拡張であるています。理解し、これに関連して、オプションタグがリクエストにSupportedヘッダフィールドに含まれることを意味します。

Values appropriate for use with this feature tag: Token with an equality relationship. Values are taken from the option tags table in the IANA SIP parameters registry.

平等な関係を持つトークン：この機能タグで使用するための適切な値。値は、IANAのSIPパラメータをレジストリにオプションタグテーブルから取得されます。

Examples of typical use: Choosing to communicate with a phone that supports quality of service preconditions instead of one that does not.

典型的な使用例：代わりにしないもののサービスの前提条件の品質をサポートして携帯電話と通信するために選択します。

Related standards or documents: RFC 3840

関連する規格または文書：RFC 3840

Security Considerations: Security considerations for this media feature tag are discussed in Section 11.1 of RFC 3840.

セキュリティの考慮：このメディアフィーチャータグに関するセキュリティの考慮事項は、RFC 3840のセクション11.1で議論されています。

10.16. Schemes

10.16. スキーム

Media feature tag name: sip.schemes

メディアフィーチャータグ名：sip.schemes

ASN.1 Identifier: 1.3.6.1.8.4.16

ASN.1識別子：1.3.6.1.8.4.16

Summary of the media feature indicated by this tag: Each value of the sip.schemes (note the plurality) media feature tag indicates a URI scheme [10] that is supported by a UA. Supported implies, for

このタグで示されるメディア機能の概要：sip.schemesの各値（複数のことに注意）、メディア特徴タグは、UAによってサポートされているURIスキーム[10]を示します。サポートされているため、意味

example, that the UA would know how to handle a URI of that scheme in the Contact header field of a redirect response.

たとえば、UAがリダイレクト応答のContactヘッダーフィールドにそのスキームのURIを処理する方法を知っているだろうということ。

Values appropriate for use with this feature tag: Token with an equality relationship. Values are taken from the IANA URI scheme registry.

平等な関係を持つトークン：この機能タグで使用するための適切な値。値は、IANAのURIスキームレジストリから取得されます。

Examples of typical use: Choosing to get redirected to a phone number when a called party is busy, rather than a web page.

典型的な使用例：着信側がビジー状態のときの電話番号にリダイレクトするために選択するのではなく、Webページ。

Related standards or documents: RFC 3840

関連する規格または文書：RFC 3840

Security Considerations: Security considerations for this media feature tag are discussed in Section 11.1 of RFC 3840.

セキュリティの考慮：このメディアフィーチャータグに関するセキュリティの考慮事項は、RFC 3840のセクション11.1で議論されています。

10.17. Actor

10.17. 俳優

Media feature tag name: sip.actor

メディアフィーチャータグ名：sip.actor

ASN.1 Identifier: 1.3.6.1.8.4.17

ASN.1識別子：1.3.6.1.8.4.17

Summary of the media feature indicated by this tag: This feature tag indicates the type of entity that is available at this URI.

このタグで示されるメディア機能の概要：この特徴タグは、このURIで利用可能であるエンティティのタイプを示します。

Values appropriate for use with this feature tag: Token with an equality relationship. The following values are defined:

平等な関係を持つトークン：この機能タグで使用するための適切な値。次の値が定義されています。

principal: The device provides communication with the principal that is associated with the device. Often this will be a specific human being, but it can be an automata (for example, when calling a voice portal).

プリンシパル：デバイスは、デバイスに関連付けられている主との通信を提供します。多くの場合、これは特定の人間になりますが、それはオートマトンことができる（例えば、音声ポータルを呼び出すとき）。

attendant: The device provides communication with an automaton or person that will act as an intermediary in contacting the principal associated with the device, or a substitute.

係員：デバイスがデバイス、又は代替に関連付けられたプリンシパルを接触させるに仲介として作用するオートマトン又は人との通信を提供します。

msg-taker: The device provides communication with an automaton or person that will take messages and deliver them to the principal.

MSG-係：デバイスがメッセージを取得し、校長にそれらをお届けしますオートマトンや人との通信を提供します。

information: The device provides communication with an automaton or person that will provide information about the principal.

情報：デバイスは、プリンシパルについての情報を提供するオートマトン又は人との通信を提供します。

Examples of typical use: Requesting that a call not be routed to voicemail.

典型的な使用例：コールがボイスメールにルーティングされないことを要求します。

Related standards or documents: RFC 3840

関連する規格または文書：RFC 3840

Security Considerations: Security considerations for this media feature tag are discussed in Section 11.1 of RFC 3840.

セキュリティの考慮：このメディアフィーチャータグに関するセキュリティの考慮事項は、RFC 3840のセクション11.1で議論されています。

10.18. Is Focus

10.18. フォーカスがあります

Media feature tag name: sip.isfocus

メディアフィーチャータグ名：sip.isfocus

ASN.1 Identifier: 1.3.6.1.8.4.18

ASN.1識別子：1.3.6.1.8.4.18

Summary of the media feature indicated by this tag: This feature tag indicates that the UA is a conference server, also known as a focus, and will mix together the media for all calls to the same URI [13].

このタグで示されるメディア機能の概要：この機能タグは、フォーカスとして知られている、UAは、会議サーバであることを示し、そして同じURI [13]へのすべての呼び出しのために一緒にメディアを混合します。

Values appropriate for use with this feature tag: Boolean.

ブール：この機能タグで使用するための適切な値。

Examples of typical use: Indicating to a UA that the server to which it has connected is a conference server.

典型的な使用例：それが接続されているサーバーは、会議サーバであるUAに指示。

Related standards or documents: RFC 3840

関連する規格または文書：RFC 3840

Security Considerations: Security considerations for this media feature tag are discussed in Section 11.1 of RFC 3840.

セキュリティの考慮：このメディアフィーチャータグに関するセキュリティの考慮事項は、RFC 3840のセクション11.1で議論されています。

11. Security Considerations

11.セキュリティについての考慮事項

11.1. Considerations for Media Feature Tags

11.1. メディア特徴タグの考慮事項

This section discusses security considerations for the media feature tags, including, but not limited to, this specification.

このセクションでは、メディア特徴タグのセキュリティに関する考慮事項について説明を含め、この仕様が、これらに限定されません。

The media feature tags defined in Section 10 reveal sensitive information about a user or the user agent they are describing. Some of the feature tags convey capability information about the agent - for example, the media types it can support, the SIP methods it can support, and the SIP extensions it can support. This capability information might be used for industrial espionage, for example, and so its protection may be important. Other attributes, such as the mobility, priority, and isfocus attributes, reveal characteristics of the user agent. These attributes are more sensitive than the capability information. They describe the way in which a user agent is utilized by a user, and thus reveal information about user preferences and the ways in which they want calls handled. Some feature tags, such as languages, reveal information about the user themself. As a result, applications which utilize these media feature tags SHOULD provide a means for ensuring their confidentiality.

第10節で定義されたメディア特徴タグは、ユーザーや、彼らが記述されているユーザエージェントに関する機密情報を明らかにする。フィーチャータグの中には、エージェントに関する能力情報を伝える - 例えば、メディアタイプが、それは、それがサポートできるSIP方法、およびそれをサポートできるSIPの拡張をサポートすることができます。この機能情報は、例えば、産業スパイのために使用されるかもしれない、のでその保護が重要であるかもしれません。このような移動度、優先順位、およびisfocus属性などの他の属性は、ユーザエージェントの特性を明らかにする。これらの属性は、能力情報よりも敏感です。彼らは、ユーザエージェントがユーザによって利用される方法を説明し、これにより、ユーザの好みや、彼らが処理したコールを先の方法についての情報を明らかにしました。そのような言語など、一部の機能タグは、ユーザー人自身についての情報を明らかにしました。その結果、これらのメディア特徴タグを利用するアプリケーションは、その機密性を確保するための手段を提供する必要があります。

The media feature tags can be used in ways which affect application behaviors. For example, the SIP caller preferences extension [11] allows for call routing decisions to be based on the values of these parameters. Therefore, if an attacker can modify the values of these feature tags, they may be able to affect the behavior of applications. As a result of this, applications which utilize these media feature tags SHOULD provide a means for ensuring their integrity. Similarly, media feature tags should only be trusted as valid when they come from the user or user agent described by those feature tags. As a result, mechanisms for conveying feature tags SHOULD provide a mechanism for guaranteeing authenticity.

メディア特徴タグは、アプリケーションの動作に影響を与える方法で使用することができます。例えば、SIP発信者の好みの拡張[11]これらのパラメータの値に基づくように、コールルーティングの決定を可能にします。攻撃者がこれらの機能タグの値を変更することができればそれゆえ、彼らは、アプリケーションの動作に影響を与えることができるかもしれません。その結果、これらのメディア特徴タグを利用するアプリケーションは、その完全性を保証するための手段を提供する必要があります。彼らはそれらの機能タグによって記述されたユーザーまたはユーザーエージェントから来る場合も同様に、メディア特徴タグは、唯一の有効なとして信頼されなければなりません。その結果、特徴タグを搬送するためのメカニズムは、真正性を保証するためのメカニズムを提供しなければなりません。

11.2. Considerations for Registrations

11.2. 登録のための考慮事項

As per the general requirements in Section 11.1, when media feature tags are carried in a registration, authenticity, confidentiality, and integrity need to be provided. To accomplish this, registrations containing capability information SHOULD be made by addressing the registration to a SIPS URI (in other words, the Request URI of the request would be sips:example.com when creating a registration in the example.com domain). Furthermore, the registrar SHOULD challenge the UA using digest over TLS, to verify its authenticity. The combination of TLS and digest provide integrity, confidentiality, and authenticity, as required.

11.1節での一般的な要件に応じて、メディア特徴タグを登録、信憑性、機密性、および整合性に運ばれるときに提供する必要があります。これを実現するために、能力情報を含む登録はSIPS URI（：example.com example.comドメインの登録を作成するときに、他の言葉で、リクエストのリクエストURIがSIPSだろう）への登録をアドレスすることによってなされるべきです。さらに、レジストラは、その信憑性を検証するために、TLS上のダイジェストを使用してUAに挑戦すべきです。 TLSの組み合わせ、必要に応じて、整合性、機密性、および信頼性を提供ダイジェスト。

It is not necessary for the Contact in the registration to itself contain a sips URI, since the feature tags are not carried in incoming requests sent to the UA.

フィーチャータグはUAに送信された着信要求で運ばれていないので、それ自体への登録で連絡先は、SIPS URIが含まれている必要はありません。

11.3. Considerations for OPTIONS Responses

11.3. OPTIONS応答のための考慮事項

When including information on capabilities in a response to an OPTIONS request, a UA SHOULD verify with the user (either through a user interface or though prior configuration) whether or not capability information should be divulged to the requester. If the identity of the requester cannot be cryptographically verified (using digest or the SIP identity enhancements [15]), the user SHOULD also be alerted to this fact, and be allowed to choose whether such information should be divulged.

OPTIONS要求に応答して機能に関する情報を含む場合、UAは、能力情報を要求者に公表されるべきであるか否か（ユーザインターフェースを介して、または事前構成ただしいずれか）をユーザに確認する必要があります。要求者のアイデンティティが暗号（ダイジェストまたはSIPアイデンティティの強化[15]を使用して）確認することができない場合、ユーザは、この事実を警告する必要があり、そのような情報を公表する必要があるかどうかを選択させること。

If the user does wish to reveal capability information to the requester, and wishes to guarantee its confidentiality, but the request did not arrive using SIPS, the UAS SHOULD redirect the request to a sips URI. This will cause the UAC to send the OPTIONS request using SIPS instead, and therefore provide confidentiality of any responses sent over the secure connections.

ユーザーが要求者に能力情報を明らかにしたいし、その機密性を保証したいが、リクエストがSIPSを使用して到着しなかったならば、UASはSIPS URIに要求をリダイレクトする必要があります。これは、代わりにSIPSを使用してOPTIONS要求を送信するため、セキュアな接続を介して送信されたすべての回答の機密性を提供するために、UACが発生します。

Furthermore, S/MIME MAY be used in the OPTIONS response. In that case, the capability information would be contained only in the secured S/MIME body, and not in the header fields of the OPTIONS response.

また、S / MIMEは、OPTIONS応答に使用されるかもしれません。その場合に、能力情報は、セキュリティで保護されたS / MIME本体ではなく、OPTIONS応答のヘッダフィールドに含まれることになります。

11.4. Considerations for Dialog Initiating Messages

11.4. ダイアログの開始メッセージの考慮事項

When a UAS generates a response that will initiate a dialog, and they wish to include capability information in the Contact header field, the same considerations as described in Section 11.3 apply.

UASは、ダイアログを開始します応答を生成し、それらはContactヘッダーフィールドに能力情報を含めたい場合は、11.3節で説明したのと同様の考慮事項が適用されます。

When a UAC generates a request that will initiate a dialog, it SHOULD obtain permission from the user (either through a user interface or apriori configuration) before including capability information in the Contact header field of the request. Confidentiality and integrity of the information SHOULD be provided using SIPS. S/MIME MAY be used.

UACがダイアログを開始する要求を生成すると、その要求のContactヘッダフィールドの能力情報を含む前（いずれかのユーザインタフェースまたはアプリオリ構成を介して）ユーザから許可を得なければなりません。情報の機密性と整合性がSIPSを使用して提供されるべきです。 S / MIMEを使用することができます。

12. IANA Considerations

12. IANAの考慮事項

There are a number of IANA considerations associated with this specification.

この仕様に関連付けられているIANAの考慮事項がいくつかあります。

12.1. SIP Media Feature Tag Registration Tree

12.1. SIPメディアフィーチャータグの登録ツリー

This specification serves to create a new media feature tag registration tree, per the guidelines of Section 3.1.4 of RFC 2506 [3]. The name of this tree is the "SIP Media Feature Tag Registration Tree", and its prefix is "sip.". It is used for the registration of media feature tags that are applicable to the Session

この仕様は、[3] RFC 2506のセクション3.1.4のガイドラインごとに、新しいメディア特徴タグ登録ツリーを作成するのに役立ちます。この木の名前は、「SIPメディアフィーチャータグの登録ツリー」であり、その接頭辞は「一口。」。それは、セッションに適用されるメディア特徴タグの登録に使用されます

Initiation Protocol, and whose meaning is only defined within that usage.

イニシエーション・プロトコル、およびその意味だけでその用法内で定義されています。

The addition of entries into this registry occurs through IETF consensus, as defined in RFC 2434 [18]. This requires the publication of an RFC that contains the registration. The information required in the registration is identical to the IETF tree. As such, specifications adding entries to the registry should use the template provided in Section 3.4 of RFC 2506. Note that all media feature tags registered in the SIP tree will have names with a prefix of "sip.". No leading "+" is used in the registrations in any of the media feature tag trees.

RFC 2434 [18]で定義されるようにこのレジストリへのエントリの追加は、IETFコンセンサスを介して生じます。これは、登録が含まれているRFCの発行が必要です。登録に必要な情報は、IETFツリーと同じです。このようにして、レジストリにエントリを追加する仕様は、SIPツリーに登録されているすべてのメディア特徴タグはプレフィックスと名前がありますRFC 2506ノートのセクション3.4で提供されるテンプレートを使用する必要があり、「一口。」。「+」をリードするメディア特徴タグツリーのいずれかに登録して使用されていないん。

12.2. Media Feature Tags

12.2. メディア特徴タグ

This specification registers a number of new Media feature tags according to the procedures of RFC 2506 [3]. These registrations are all made in the newly created SIP tree for media feature tags. These registrations are:

この仕様は、RFC 2506の手順に従って新しいメディア特徴タグの番号を登録する[3]。これらの登録は、すべてのメディア特徴タグ用に新しく作成したSIPの木で作られています。これらの登録は、以下のとおりです。

sip.audio: The information for registering the sip.audio media feature tag is contained in Section 10.1.

sip.audio：sip.audioメディアフィーチャータグの登録情報は、セクション10.1に含まれています。

sip.application: The information for registering the sip.application media feature tag is contained in Section 10.2.

sip.application：sip.applicationメディアフィーチャータグの登録情報は、セクション10.2に含まれています。

sip.data: The information for registering the sip.data media feature tag is contained in Section 10.3.

sip.data：sip.dataメディアフィーチャータグの登録情報は、セクション10.3に含まれています。

sip.control: The information for registering the sip.control media feature tag is contained in Section 10.4.

sip.control：sip.controlメディアフィーチャータグの登録情報は、セクション10.4に含まれています。

sip.video: The information for registering the sip.video media feature tag is contained in Section 10.5.

sip.video：sip.videoメディアフィーチャータグの登録情報は、セクション10.5に含まれています。

sip.text: The information for registering the sip.text media feature tag is contained in Section 10.6.

sip.text：sip.textメディアフィーチャータグの登録情報は、セクション10.6に含まれています。

sip.automata: The information for registering the sip.automata media feature tag is contained in Section 10.7.

sip.automata：sip.automataメディアフィーチャータグの登録情報は、セクション10.7に含まれています。

sip.class: The information for registering the sip.class media feature tag is contained in Section 10.8.

sip.class：sip.classメディアフィーチャータグの登録情報は、セクション10.8に含まれています。

sip.duplex: The information for registering the sip.duplex media feature tag is contained in Section 10.9.

sip.duplex：sip.duplexメディアフィーチャータグの登録情報は、セクション10.9に含まれています。

sip.mobility: The information for registering the sip.mobility media feature tag is contained in Section 10.10.

sip.mobility：sip.mobilityメディアフィーチャータグの登録情報は、セクション10.10に含まれています。

sip.description: The information for registering the sip.description media feature tag is contained in Section 10.11.

sip.description：sip.descriptionメディアフィーチャータグの登録情報は、セクション10.11に含まれています。

sip.events: The information for registering the sip.events media feature tag is contained in Section 10.12.

sip.events：sip.eventsメディアフィーチャータグの登録情報は、セクション10.12に含まれています。

sip.priority: The information for registering the sip.priority media feature tag is contained in Section 10.13.

sip.priority：sip.priorityメディアフィーチャータグの登録情報は、セクション10.13に含まれています。

sip.methods: The information for registering the sip.methods media feature tag is contained in Section 10.14.

sip.methods：sip.methodsメディアフィーチャータグの登録情報は、セクション10.14に含まれています。

sip.extensions: The information for registering the sip.extensions media feature tag is contained in Section 10.15.

sip.extensions：sip.extensionsメディアフィーチャータグの登録情報は、セクション10.15に含まれています。

sip.schemes: The information for registering the sip.schemes media feature tag is contained in Section 10.16.

sip.schemes：sip.schemesメディアフィーチャータグの登録情報は、セクション10.16に含まれています。

sip.actor: The information for registering the sip.actor media feature tag is contained in Section 10.17.

sip.actor：sip.actorメディアフィーチャータグの登録情報は、セクション10.17に含まれています。

sip.isfocus: The information for registering the sip.isfocus media feature tag is contained in Section 10.18.

sip.isfocus：sip.isfocusメディアフィーチャータグの登録情報は、セクション10.18に含まれています。

12.3. SIP Option Tag

12.3. SIPオプションタグ

This specification registers a single SIP option tag, pref. The required information for this registration, as specified in RFC 3261 [1], is:

この仕様は、県、単一のSIPオプションタグを登録します。この登録に必要な情報、RFC 3261で指定されるように[1]です。

Name: pref

名前：県

Description: This option tag is used in a Require header field of a registration to ensure that the registrar supports the caller preferences extensions.

説明：このオプションタグは、レジストラは、発信者の嗜好の拡張をサポートしていることを保証するために、登録のRequireヘッダーフィールドで使用されています。

13. Acknowledgments

13.謝辞

The initial set of media feature tags used by this specification were influenced by Scott Petrack's CMA design. Jonathan Lennox, Bob Penfield, Ben Campbell, Mary Barnes, Rohan Mahy, and John Hearty provided helpful comments. Graham Klyne provided assistance on the usage of RFC 2533. Thanks to Allison Mankin for her comments and support, and to Ted Hardie for his guidance on usage of the media feature tags.

この仕様で使用されるメディアフィーチャータグの初期セットは、スコット2000 PetrackとのCMAのデザインに影響を受けました。ジョナサン・レノックス、ボブペンフィールド、ベン・キャンベル、メアリー・バーンズ、ローハンマーイ、およびジョン・ハーティは役に立つコメントを提供しました。グラハムKlyneはメディア特徴タグの使用に関する彼の指導のためにとテッドハーディーに、彼女のコメントやサポートのために2533のおかげアリソンマンキンへのRFCの使用に援助を提供します。

14. References

14.参考文献

14.1. Normative References

14.1. 引用規格

[1] 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.

[1]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。

[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[2]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。

[3] Holtman, K., Mutz, A., and T. Hardie, "Media Feature Tag Registration Procedure", BCP 31, RFC 2506, March 1999.

[3] Holtman、K.、MUTZ、A.、およびT.ハーディ、 "メディア特徴タグの登録手順"、BCP 31、RFC 2506、1999年3月。

[4] Klyne, G., "A Syntax for Describing Media Feature Sets", RFC 2533, March 1999.

[4] "メディア機能セットの記述のための構文" Klyne、G.、RFC 2533を、1999年3月。

[5] Klyne, G., "Corrections to "A Syntax for Describing Media Feature Sets"", RFC 2738, December 1999.

[5] Klyne、G.、 "訂正する "構文メディア機能セット""、RFC 2738の記述のために、1999年12月。

[6] Hoffman, P., "Registration of Charset and Languages Media Features Tags", RFC 2987, November 2000.

[6]ホフマン、P.は、RFC 2987、2000年11月 "文字セットと言語メディアの登録はタグ機能します"。

[7] Klyne, G., "MIME Content Types in Media Feature Expressions", RFC 2913, September 2000.

[7] Klyne、G.、 "メディア特徴式でのMIMEコンテンツタイプ"、RFC 2913、2000年9月。

[8] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.

[8]ハンドレー、M.およびV. Jacobsonの "SDP：セッション記述プロトコル"、RFC 2327、1998年4月。

[9] Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.

[9]ローチ、A.B.、 "セッション開始プロトコル（SIP）特異的イベント通知"、RFC 3265、2002年6月。

[10] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.

[10]バーナーズ=リー、T.、フィールディング、R.、およびL. Masinter、 "統一資源識別子（URI）：一般的な構文"、RFC 2396、1998年8月。

14.2. Informative References

14.2. 参考文献

[11] Rosenberg, J., Schulzrinne, H. and P. Kyzivat, "Caller Preferences for the Session Initiation Protocol (SIP)", RFC 3841, August 2004.

[11]ローゼンバーグ、J.、Schulzrinneと、H.及びP. Kyzivat、 "セッション開始プロトコル（SIP）のための発呼者が設定"、RFC 3841、2004年8月。

[12] Mahy, R., "A Message Summary and Message Waiting Indication Event Package for the Session Initiation Protocol (SIP)", RFC 3842, August 2004.

[12]マーイ、R.、RFC 3842、2004年8月「セッション開始プロトコル（SIP）のためのメッセージサマリとメッセージ待機表示イベントパッケージ」。

[13] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol", Work in Progress, May 2003.

[13]ローゼンバーグ、J.、「セッション開始プロトコルとの会議のための枠組み」、進歩、2003年5月での作業。

[14] Howes, T. and M. Smith, "LDAP: String Representation of Search Filters", Work in Progress, March 2003.

[14]ハウズ、T.およびM.スミス、 "LDAP：検索フィルタの文字列表現"、進歩、2003年3月での作業。

[15] Peterson, J., "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", Work in Progress, March 2003.

[15]ピーターソン、J.、進歩、2003年3月に仕事「セッション開始プロトコル（SIP）で認証されたアイデンティティ管理のための機能強化」。

[16] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002.

[16]キャンベル、B.、ローゼンバーグ、J.、Schulzrinneと、H.、のHuitema、C.、およびD. Gurle、 "インスタントメッセージングのためのセッション開始プロトコル（SIP）拡張子"、RFC 3428、2002年12月。

[17] Klyne, G., "Protocol-independent Content Negotiation Framework", RFC 2703, September 1999.

[17] Klyne、G.、 "プロトコルに依存しないコンテンツネゴシエーションフレームワーク"、RFC 2703、1999年9月。

[18] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

、BCP 26、RFC 2434、1998年10月[18] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"。

Appendix A. Overview of

付録A.概要

This section provides a brief overview of RFC 2533 and related specifications that form the content negotiation framework. This section does not represent normative behavior. In the event of any conflict between the tutorial material here and the normative text in RFC 2533, RFC 2533 takes precedence.

このセクションでは、コンテンツの交渉の枠組みを形成RFC 2533および関連する仕様の概要を説明します。このセクションでは、規範的行動を表すものではありません。ここでは、チュートリアル材料とRFC 2533で規定テキストの間の矛盾が生じた場合には、RFC 2533が優先されます。

A critical concept in the framework is that of a feature set. A feature set is information about an entity (in our case, a UA), which describes a set of features it can handle. A feature set can be thought of as a region in N-dimensional space. Each dimension in this space is a different media feature, identified by a media feature tag. For example, one dimension (or axis) might represent languages, another might represent methods, and another, MIME types. A feature collection represents a single point in this space. It represents a particular rendering or instance of an entity (in our case, a UA). For example, a "rendering" of a UA would define an instantaneous mode of operation that it can support. One such rendering would be processing the INVITE method, which carried the application/sdp MIME type, sent to a UA for a user that is speaking English.

フレームワークの重要なコンセプトは、機能セットのことです。機能セットは、それが扱うことができる機能のセットを記述し、（私たちの場合、UAで）エンティティに関する情報です。機能セットは、N次元空間における領域として考えることができます。このスペース内の各ディメンションは、メディア特徴タグで識別異なるメディア機能、です。例えば、一次元（又は軸）は、別の方法を表すことが、言語を表す可能性があり、別の、MIMEタイプ。機能コレクションは、この空間での単一のポイントを表します。これは、（我々の場合、UA）エンティティの特定のレンダリング又はインスタンスを表します。たとえば、UAの「レンダリング」は、それがサポートできる操作の瞬間のモードを定義します。そのようなレンダリングは、英語を話しているユーザーのためにUAに送信されたアプリケーション/ SDP MIMEタイプを、実施INVITE方法を、処理されるだろう。

A feature set can therefore be defined as a set of feature collections. In other words, a feature set is a region of N-dimensional feature-space, that region being defined by the set of points - feature collections - that make up the space. If a particular feature collection is in the space, it means that the rendering described by that feature collection is supported by the device with that feature set.

機能セットは、そのための機能のコレクションのセットとして定義することができます。機能コレクション - - 空間を構成する機能セットは、N次元特徴空間の領域であり、換言すれば、その領域は、点の集合によって定義されます。特定の機能のコレクションが空間にある場合は、その機能の集まりで記述レンダリングがその機能セットを持つデバイスでサポートされていることを意味します。

How does one represent a feature set? There are many ways to describe an N-dimensional space. One way is to identify mathematical functions which identify its contours. Clearly, that is too complex to be useful. The solution taken in RFC 2533 is to define the space with a feature set predicate. A feature predicate defines a relation over an N-dimensional space; its input is any point in that space (i.e., a feature collection), and is true for all points that are in the region thus defined.

どのようにして機能セットを表しているのでしょうか？ N次元空間を記述するための多くの方法があります。一つの方法は、その輪郭を特定する数学関数を識別することです。明らかに、それは有用であることがあまりにも複雑です。 RFC 2533で撮影したソリューションは、述語を設定する機能とスペースを定義することです。特徴述語はN次元空間上の関係を定義します。その入力は、スペース（すなわち、機能コレクション）内の任意の点であり、このように定義された領域内にある全ての点についても同様です。

RFC 2533 describes a syntax for writing down these N-dimensional boolean functions, borrowed from LDAP [14]. It uses a prolog-style syntax which is fairly self-explanatory. This representation is called a feature set predicate. The base unit of the predicate is a filter, which is a boolean expression encased in round brackets. A filter can be complex, where it contains conjunctions and disjunctions of other filters, or it can be simple. A simple filter is one that expresses a comparison operation on a single media feature tag.

RFC 2533は、LDAP [14]から借りこれらのN次元のブール関数を、書き留めの構文について説明します。それはかなり自明であるプロローグスタイルの構文を使用しています。この表現は、述語を設定する機能と呼ばれています。述語のベース部は、丸括弧に入れられたブール式であるフィルタです。それは接続詞や他のフィルタの論理和を含んでいる場合、フィルタは、複雑になることがあります、またはそれはシンプルにすることができます。単純なフィルタは、単一のメディア特徴タグに比較演算を発現するものです。

For example, consider the feature set predicate:

例えば、機能セットの述語を考えてみます。

(& (foo=A) (bar=B) (| (baz=C) (& (baz=D) (bif=E))))

（＆（FOO = A）（バー= B）（|（バズ= C）（＆（バズ= D）（BIF = E））））

This defines a function over four media features - foo, bar, baz, and bif. Any point in feature space with foo equal to A, bar equal to B, and baz equal to either C or D, and bif equal to E, is in the feature set defined by this feature set predicate.

FOO、バー、バズ、およびBIF - これは、4つのメディア機能を超える機能を定義します。 Aに等しいFOO、Bに等しいバー、C又はDのいずれかに等しいバズ、およびEに等しいBIFと特徴空間内の任意の点では、この機能セット述語によって定義された機能セットです。

Note that the predicate doesn't say anything about the number of dimensions in feature space. The predicate operates on a feature space of any number of dimensions, but only those dimensions labeled foo, bar, baz, and bif matter. The result is that values of other media features don't matter. The feature collection {foo=A,bar=B,baz=C,bop=F} is in the feature set described by the predicate, even though the media feature tag "bop" isn't mentioned. Feature set predicates are therefore inclusive by default. A feature collection is present unless the boolean predicate rules it out. This was a conscious design choice in RFC 2533.

述語は、特徴空間の次元数については何も言っていないことに注意してください。述語は、任意の数の次元の特徴空間上で動作しますが、FOO、バー、バズ、およびBIF事項をラベルのみ寸法。その結果は、他のメディア機能の値が重要ではないということです。特徴集合{FOO = A、バー= B、バズ= C、BOP = F}はメディア特徴タグ「BOP」が言及されていなくても、述語によって記述機能セットです。機能セットの述語は、そのため、デフォルトで含まれています。ブール述語がそれを除外しない限り、機能のコレクションが存在しています。これは、RFC 2533で意識的な設計上の選択でした。

RFC 2533 also talks about matching a preference with a capability set. This is accomplished by representing both with a feature set. A preference is a feature set - its a specification of a number of feature collections, any one of which would satisfy the requirements of the sender. A capability is also a feature set - its a specification of the feature collections that the recipient supports. There is a match when the spaces defined by both feature sets overlap. When there is overlap, there exists at least one feature collection that exists in both feature sets, and therefore a modality or rendering desired by the sender which is supported by the recipient.

RFC 2533はまた、能力セットとの嗜好に合っについて語っています。これは、両方の機能セットを用いて表現することによって達成されます。フィーチャーコレクションの数のその仕様、送信者の要件を満たすことになるのいずれか - 好みは機能セットです。受信者がサポートしている機能のコレクションのその仕様 - 性能も機能セットです。両方の機能セットによって定義された空間が重なったときに試合があります。重複がある場合、少なくとも1つの特徴の両方の機能セットに存在する収集、および受信者によって支持されている送信者が所望従ってモダリティ又はレンダリングが存在します。

This leads directly to the definition of a match. Two feature sets match if there exists at least one feature collection present in both feature sets.

これは、試合の定義に直結します。両方の機能セットに存在する少なくとも1つの特徴のコレクションが存在する場合、2つの機能セットが一致します。

Computing a match for two general feature set predicates is not easy. Section 5 of RFC 2533 presents an algorithm for doing it by expanding an arbitrary expression into disjunctive normal form. However, the feature set predicates used by this specification are constrained. They are always in conjunctive normal form, with each term in the conjunction describing values for different media features. This makes computation of a match easy. It is computed independently for each media feature, and then the feature sets overlap if media features specified in both sets overlap. Computing the overlap of a single media feature is very straightforward, and is a simple matter of computing whether two finite sets overlap.

二つの一般的な機能セットの述語の一致を計算することは容易ではありません。 RFC 2533のセクション5は、選言標準形に任意の式を展開することによってそれを行うためのアルゴリズムを示します。しかし、この仕様で使用される機能セットの述語が拘束されています。それらは異なるメディア機能の値を記述する関連して、各用語と、連言標準形に常にあります。これは、試合の計算が容易になります。これは、各メディア機能のために独立して計算され、両方のセットで指定されたメディア機能が重複するならば、特徴セットが重複しています。単一のメディア機能の重複を計算することは非常に簡単であり、2つの有限集合が重なるかどうかを計算することは簡単なことです。

Authors' Addresses

著者のアドレス

Jonathan Rosenberg dynamicsoft 600 Lanidex Plaza Parsippany, NJ 07054 US

ジョナサン・ローゼンバーグdynamicsoft 600 Lanidexプラザパーシッパニー、NJ 07054米国

Phone: +1 973 952-5000 EMail: jdrosen@dynamicsoft.com URI: http://www.jdrosen.net

電話：+1 973 952-5000 Eメール：jdrosen@dynamicsoft.com URI：http://www.jdrosen.net

Henning Schulzrinne Columbia University M/S 0401 1214 Amsterdam Ave. New York, NY 10027 US

ヘニングSchulzrinneとコロンビア大学のM / S 0401 1214アムステルダムアベニュー。ニューヨーク、NY 10027米国

EMail: schulzrinne@cs.columbia.edu URI: http://www.cs.columbia.edu/~hgs

電子メール：schulzrinne@cs.columbia.edu URI：http://www.cs.columbia.edu/~hgs

Paul Kyzivat Cisco Systems 1414 Massachusetts Avenue BXB500 C2-2 Boxboro, MA 01719 US

ポールKyzivatシスコシステムズ1414年マサチューセッツアベニューBXB500 C2-2 Boxboro、MA 01719米国

EMail: pkyzivat@cisco.com

メールアドレス：pkyzivat@cisco.com

Full Copyright Statement

完全な著作権声明

Copyright (C) The Internet Society (2004). 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.

著作権（C）インターネット協会（2004）。この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。

Intellectual Property

知的財産

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。

Acknowledgement

謝辞

Funding for the RFC Editor function is currently provided by the Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。