[要約] RFC 3841は、SIPにおける呼び出し元の設定を定義するものであり、呼び出し元の優先順位や制約を指定するための仕組みを提供します。このRFCの目的は、SIPセッションの品質や機能を向上させるために、呼び出し元の要求を適切に処理するためのガイドラインを提供することです。
Network Working Group J. Rosenberg
Request for Comments: 3841 dynamicsoft
Category: Standards Track H. Schulzrinne
Columbia University
P. Kyzivat
Cisco Systems
August 2004
Caller Preferences for the Session Initiation Protocol (SIP)
セッション開始プロトコル（SIP）の発信者の好み
Status of this Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004).
著作権（c）The Internet Society（2004）。
Abstract
概要
This document describes a set of extensions to the Session Initiation Protocol (SIP) which allow a caller to express preferences about request handling in servers. These preferences include the ability to select which Uniform Resource Identifiers (URI) a request gets routed to, and to specify certain request handling directives in proxies and redirect servers. It does so by defining three new request header fields, Accept-Contact, Reject-Contact, and Request-Disposition, which specify the caller's preferences.
このドキュメントでは、セッション開始プロトコル（SIP）への一連の拡張機能について説明します。これにより、発信者はサーバーでのリクエスト処理に関する好みを表現できます。これらの設定には、リクエストがルーティングされる均一なリソース識別子（URI）を選択し、プロキシで特定のリクエスト処理ディレクティブを指定し、サーバーをリダイレクトする機能が含まれます。これは、3つの新しいリクエストヘッダーフィールドを定義し、受け入れコンタクト、拒否コンタクト、およびリクエスト配置を定義し、発信者の好みを指定します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Overview of Operation . . . . . . . . . . . . . . . . . . . . 4
5. UAC Behavior . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Request Handling Preferences . . . . . . . . . . . . . . 6
5.2. Feature Set Preferences . . . . . . . . . . . . . . . . 6
6. UAS Behavior . . . . . . . . . . . . . . . . . . . . . . . . . 8
7. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Request-Disposition Processing . . . . . . . . . . . . . 9
7.2. Preference and Capability Matching . . . . . . . . . . . 9
7.2.1. Extracting Explicit Preferences . . . . . . . . . 10
7.2.2. Extracting Implicit Preferences . . . . . . . . . 10
7.2.2.1. Methods. . . . . . . . . . . . . . . . . 10
7.2.2.2. Event Packages . . . . . . . . . . . . . 11
7.2.3. Constructing Contact Predicates . . . . . . . . . 11
7.2.4. Matching. . . . . . . . . . . . . . . . . . . . . 12
7.2.5. Example . . . . . . . . . . . . . . . . . . . . . 16
8. Mapping Feature Parameters to a Predicate. . . . . . . . . . . 17
9. Header Field Definitions . . . . . . . . . . . . . . . . . . . 19
9.1. Request Disposition . . . . . . . . . . . . . . . . . . 20
9.2. Accept-Contact and Reject-Contact Header Fields . . . . 21
10. Augmented BNF . . . . . . . . . . . . . . . . . . . . . . . . 22
11. Security Considerations . . . . . . . . . . . . . . . . . . . 22
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
14.1. Normative References . . . . . . . . . . . . . . . . . . 24
14.2. Informative References . . . . . . . . . . . . . . . . . 24
15. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25
16. Full Copyright Statements. . . . . . . . . . . . . . . . . . . 26
When a Session Initiation Protocol (SIP) [1] server receives a request, there are a number of decisions it can make regarding the processing of the request. These include:
セッション開始プロトコル（SIP）[1]サーバーがリクエストを受信すると、リクエストの処理に関して多くの決定があります。これらには以下が含まれます：
o whether to proxy or redirect the request
o リクエストを委任するかリダイレクトするか
o which URIs to proxy or redirect to
o どのurisがプロキシまたはリダイレクトするか
o whether to fork or not
o フォークするかどうか
o whether to search recursively or not o whether to search in parallel or sequentially
o 再帰的に検索するかどうかo並列または順次検索するかどうか
The server can base these decisions on any local policy. This policy can be statically configured, or can be based on execution of a program or database access.
サーバーは、これらの決定をローカルポリシーに基づいています。このポリシーは、静的に構成することも、プログラムまたはデータベースアクセスの実行に基づいている場合もあります。
However, the administrator of the server is the not the only entity with an interest in request processing. There are at least three parties which have an interest: (1) the administrator of the server, (2) the user that sent the request, and (3) the user to whom the request is directed. The directives of the administrator are embedded in the policy of the server. The preferences of the user to whom the request is directed (referred to as the callee, even though the request method may not be INVITE) can be expressed most easily through a script written in some type of scripting language, such as the Call Processing Language (CPL) [11]. However, no mechanism exists to incorporate the preferences of the user that sent the request (also referred to as the caller, even though the request method may not be INVITE). For example, the caller might want to speak to a specific user, but wants to reach them only at work, because the call is a business call. As another example, the caller might want to reach a user, but not their voicemail, since it is important that the caller talk to the called party. In both of these examples, the caller's preference amounts to having a proxy make a particular routing choice based on the preferences of the caller.
ただし、サーバーの管理者は、リクエスト処理に関心を持つ唯一のエンティティではありません。関心を持つ少なくとも3つのパーティーがあります。（1）サーバーの管理者、（2）リクエストを送信したユーザー、および（3）リクエストが指示されるユーザー。管理者の指令は、サーバーのポリシーに組み込まれています。リクエストが指示されているユーザーの設定（リクエスト方法が招待されない場合でも、Calleeと呼ばれます）は、コール処理言語などのあるタイプのスクリプト言語で書かれたスクリプトを使用して最も簡単に表現できます。（CPL）[11]。ただし、リクエストを送信したユーザーの設定を組み込むメカニズムはありません（リクエスト方法が招待されない場合でも、発信者とも呼ばれます）。たとえば、発信者は特定のユーザーと話をしたいかもしれませんが、通話がビジネスコールであるため、職場でのみアクセスしたいと考えています。別の例として、発信者は呼び出された当事者と話すことが重要であるため、発信者はボイスメールではなくユーザーにリーチしたいと思うかもしれません。これらの両方の例では、発信者の好みは、プロキシを持つことを、発信者の好みに基づいて特定のルーティングを選択することになります。
This extension allows the caller to have these preferences met. It does so by specifying mechanisms by which a caller can provide preferences on processing of a request. There are two types of preferences. One of them, called request handling preferences, are encapsulated in the Request-Disposition header field. They provide specific request handling directives for a server. The other, called feature preferences, is present in the Accept-Contact and Reject-Contact header fields. They allow the caller to provide a feature set [2] that expresses its preferences on the characteristics of the UA that is to be reached. These are matched with a feature set provided by a UA to its registrar [3]. The extension is very general purpose, and not tied to a particular service. Rather, it is a tool that can be used in the development of many services.
この拡張機能により、発信者はこれらの好みを満たすことができます。これは、呼び出し元がリクエストの処理に関する好みを提供できるメカニズムを指定することによって行われます。好みには2つのタイプがあります。リクエスト処理設定と呼ばれるそのうちの1つは、リクエスト拡散ヘッダーフィールドにカプセル化されています。サーバーの特定のリクエスト処理指令を提供します。もう1つは、機能設定と呼ばれ、Accept-contactおよび拒否コンタクトヘッダーフィールドに存在します。彼らは、発信者が到達するUAの特性に関する好みを表す機能セット[2]を提供できるようにします。これらは、UAがレジストラに提供する機能セットと一致します[3]。拡張機能は非常に一般的な目的であり、特定のサービスに結び付けられていません。むしろ、多くのサービスの開発に使用できるツールです。
One example of a service enabled by caller preferences is a "one number" service. A user can have a single identity (their SIP URI) for all of their devices - their cell phone, PDA, work phone, home phone, and so on. If the caller wants to reach the user at their business phone, they simply select "business phone" from a pull-down menu of options when calling that URI. Users would no longer need to maintain and distribute separate identities for each device.
発信者の設定によって有効になっているサービスの1つの例は、「1つの番号」サービスです。ユーザーは、携帯電話、PDA、ワークフォン、自宅の電話など、すべてのデバイスに単一のID（SIP URI）を持つことができます。発信者がビジネス電話でユーザーに連絡したい場合、そのURIを呼び出すときにオプションのプルダウンメニューから「ビジネス電話」を選択するだけです。ユーザーは、デバイスごとに個別のアイデンティティを維持および配布する必要がなくなります。
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [4] and indicate requirement levels for compliant implementations.
このドキュメントでは、キーワードは「必要はない」、「必須」、「必要」、「shall」、「suff」、 "nove"、 "bulsed"、 "becommended"、 "、"、 "、" optional "BCP 14、RFC 2119 [4]で説明されているように解釈され、準拠の実装の要件レベルを示します。
Much of the terminology used in this specification is presented in [3]. This specification defines the following additional terms:
この仕様で使用されている用語の多くは、[3]に示されています。この仕様では、次の追加用語を定義します。
Caller: Within the context of this specification, a caller refers to the user on whose behalf a UAC is operating. It is not limited to a user whose UAC sends an INVITE request.
発信者：この仕様のコンテキスト内で、発信者は、UACが操作しているユーザーを指します。UACが招待リクエストを送信するユーザーに限定されません。
Feature Preferences: Caller preferences that describe desired properties of a UA to which the request is to be routed. Feature preferences can be made explicit with the Accept-Contact and Reject-Contact header fields.
機能の設定：リクエストがルーティングされるUAの望ましいプロパティを記述する発信者の好み。特徴の好みは、Accept-contactおよび拒否コンタクトヘッダーフィールドを使用して明示的にすることができます。
Request Handling Preferences: Caller preferences that describe desired request treatment at a server. These preferences are carried in the Request-Disposition header field.
リクエスト処理設定：サーバーでの目的の要求トリートメントを記述する発信者の設定。これらの設定は、リクエスト拡散ヘッダーフィールドに掲載されています。
Target Set: A target set is a set of candidate URIs to which a proxy or redirect server can send or redirect a request. Frequently, target sets are obtained from a registration, but they need not be.
ターゲットセット：ターゲットセットは、プロキシまたはリダイレクトサーバーがリクエストを送信またはリダイレクトできる候補URIのセットです。多くの場合、ターゲットセットは登録から取得されますが、そうである必要はありません。
Explicit Preference: A caller preference indicated explicitly in the Accept-Contact or Reject-Contact header fields.
明示的な優先権：発信者の好みは、受け入れコンタクトまたは拒否コンタクトヘッダーフィールドで明示的に示されました。
Implicit Preference: A caller preference that is implied through the presence of other aspects of a request. For example, if the request method is INVITE, it represents an implicit caller preference to route the request to a UA that supports the INVITE method.
暗黙の好み：リクエストの他の側面の存在によって暗示される発信者の好み。たとえば、要求方法が招待されている場合、招待方法をサポートするUAにリクエストをルーティングする暗黙の発信者の好みを表します。
When a caller sends a request, it can optionally include new header fields which request certain handling at a server. These preferences fall into two categories. The first category, called request handling preferences, is carried in the Request-Disposition header field. It describes specific behavior that is desired at a server. Request handling preferences include whether the caller wishes the server to proxy or redirect, and whether sequential or parallel search is desired. These preferences can be applied at every proxy or redirect server on the call signaling path.
発信者がリクエストを送信すると、サーバーで特定の処理を要求する新しいヘッダーフィールドをオプションで含めることができます。これらの好みは2つのカテゴリに分類されます。リクエスト処理設定と呼ばれる最初のカテゴリは、リクエスト拡散ヘッダーフィールドに掲載されます。サーバーで望まれる特定の動作について説明します。リクエスト処理設定には、発信者がサーバーにプロキシまたはリダイレクトを希望するかどうか、およびシーケンシャルまたはパラレル検索が必要かどうかが含まれます。これらの設定は、コールシグナリングパスのすべてのプロキシまたはリダイレクトサーバーで適用できます。
The second category of preferences, called feature preferences, is carried in the Accept-Contact and Reject-Contact header fields. These header fields contain feature sets, represented by the same feature parameters that are used to indicate capabilities [3]. Here, the feature parameters represent the caller's preferences. The Accept-Contact header field contains feature sets that describe UAs that the caller would like to reach. The Reject-Contact header field contains feature sets which, if matched by a UA, imply that the request should not be routed to that UA.
機能設定と呼ばれる2番目のカテゴリの設定は、Accept-contactおよびReject-contactヘッダーフィールドに搭載されています。これらのヘッダーフィールドには、機能を示すために使用される同じ特徴パラメーターで表される機能セットが含まれています[3]。ここで、機能パラメーターは発信者の好みを表します。Accept-Tontactヘッダーフィールドには、発信者が到達したいUASを説明する機能セットが含まれています。拒否接続ヘッダーフィールドには、UAに一致する場合、リクエストをそのUAにルーティングしてはならないことを意味する機能セットが含まれています。
Proxies use the information in the Accept-Contact and Reject-Contact header fields to select amongst contacts in their target set. When neither of those header fields are present, the proxy computes implicit preferences from the request. These are caller preferences that are not explicitly placed into the request, but can be inferred from the presence of other message components. As an example, if the request method is INVITE, this is an implicit preference to route the call to a UA that supports the INVITE method.
プロキシは、Accept-Contactおよび拒否ヘッダーフィールドの情報を使用して、ターゲットセットの連絡先から選択します。これらのヘッダーフィールドのいずれも存在しない場合、プロキシはリクエストから暗黙の設定を計算します。これらは、要求に明示的に配置されていないが、他のメッセージコンポーネントの存在から推測できる発信者の設定です。例として、リクエスト方法が招待されている場合、これは招待方法をサポートするUAにコールをルーティングすることを暗黙的に好みます。
Both request handling and feature preferences can appear in any request, not just INVITE. However, they are only useful in requests where proxies need to determine a request target. If the domain in the request URI is not owned by any proxies along the request path, those proxies will never access a location service, and therefore, never have the opportunity to apply the caller preferences. This makes sense because typically, the request URI will identify a UAS for mid-dialog requests. In those cases, the routing decisions were already made on the initial request, and it makes no sense to redo them for subsequent requests in the dialog.
リクエストの処理と機能の設定は、招待だけでなく、任意のリクエストに表示される可能性があります。ただし、プロキシがリクエストターゲットを決定する必要があるリクエストでのみ役立ちます。リクエストのドメインがリクエストパスに沿ってプロキシが所有していない場合、それらのプロキシはロケーションサービスにアクセスすることはないため、発信者の好みを適用する機会がありません。これは理にかなっています。通常、リクエストURIはMid-DialogリクエストのUASを識別するためです。そのような場合、ルーティングの決定は最初の要求に基づいてすでに行われており、ダイアログ内のその後の要求に対してそれらをやり直すことは意味がありません。
A caller wishing to express preferences for a request includes Accept-Contact, Reject-Contact, or Request-Disposition header fields in the request, depending on their particular preferences. No additional behavior is required after the request is sent.
リクエストの好みを表現したい発信者には、特定の好みに応じて、リクエスト内の受け入れコンタクト、拒否コンタクト、またはリクエスト配置ヘッダーフィールドが含まれます。リクエストが送信された後、追加の動作は必要ありません。
The Accept-Contact, Reject-Contact, and Request-Disposition header fields in an ACK for a non-2xx final response, or in a CANCEL request, MUST be equal to the values in the original request being acknowledged or cancelled. This is to ensure proper operation through stateless proxies.
非2XX最終応答のためのACKまたはキャンセルリクエストのACK、またはキャンセルリクエストのAccept-contact、拒否、およびリクエスト拡散ヘッダーフィールドは、認められたりキャンセルされたりする元のリクエストの値に等しくなければなりません。これは、ステートレスプロキシを通じて適切な動作を確保するためです。
If the UAC wants to determine whether servers along the path understand the header fields described in this specification, it includes a Proxy-Require header field with a value of "pref" [3] in its request. If the request should fail with a 420 response code, the UAC knows that the extension is not supported. In that case, it SHOULD retry, and may decide whether or not to use caller preferences. A UA should only use Proxy-Require if knowledge about support is essential for handling of the request. Note that, in any case, caller preferences can only be considered preferences - there is no guarantee that the requested service will be executed. As such, inclusion of a Proxy-Require header field does not mean that the preferences will be executed, just that the caller preferences extension is understood by the proxies.
UACが、パスに沿ったサーバーがこの仕様で説明されているヘッダーフィールドを理解しているかどうかを判断したい場合、リクエストに「Pref」[3]の値を持つプロキシリクイアヘッダーフィールドが含まれています。420応答コードでリクエストが失敗する場合、UACは拡張機能がサポートされていないことを知っています。その場合、再試行する必要があり、発信者の好みを使用するかどうかを決定する場合があります。UAは、サポートに関する知識がリクエストの処理に不可欠である場合にのみ、プロキシリクイアを使用する必要があります。いずれにせよ、発信者の好みは好みのみと見なすことができることに注意してください - 要求されたサービスが実行されるという保証はありません。そのため、プロキシリクイアヘッダーフィールドを含めることは、発信者の好みの拡張がプロキシによって理解されていることを意味するという意味ではありません。
The Request-Disposition header field specifies caller preferences for how a server should process a request. Its value is a list of tokens, each of which specifies a particular processing directive.
リクエスト拡張ヘッダーフィールドは、サーバーがリクエストを処理する方法に対する発信者の設定を指定します。その値はトークンのリストであり、それぞれが特定の処理指令を指定します。
The syntax of the header field can be found in Section 10, and the semantics of the directives are described in Section 9.1.
ヘッダーフィールドの構文はセクション10にあり、ディレクティブのセマンティクスはセクション9.1で説明されています。
A UAC can indicate caller preferences for the capabilities of a UA that should be reached or not reached as a result of sending a SIP request. To do that, it adds one or more Accept-Contact and Reject-Contact header field values. Each header field value contains a set of feature parameters that define a feature set. The syntax of the header field can be found in Section 10, and a discussion of their usage in Section 9.2.
UACは、SIPリクエストの送信の結果として到達するか、到達しないでください。そのために、1つまたは複数のAccept-contactと拒否ヘッダーのフィールド値を追加します。各ヘッダーフィールド値には、機能セットを定義する一連の機能パラメーターが含まれています。ヘッダーフィールドの構文は、セクション10に記載されており、セクション9.2での使用について説明できます。
Each feature set is constructed as described in Section 5 of [3]. The feature sets placed into these header fields MAY overlap; that is, a UA MAY indicate preferences for feature sets that match according to the matching algorithm of RFC 2533 [2].
各機能セットは、[3]のセクション5で説明されているように構築されます。これらのヘッダーフィールドに配置された機能セットは重複する場合があります。つまり、UAは、RFC 2533の一致するアルゴリズムに従って一致する機能セットの好みを示す場合があります[2]。
A UAC can express explicit preferences for the methods and event packages supported by a UA. It is RECOMMENDED that a UA include a term in an Accept-Contact feature set with the "sip.methods" feature tag (note, however, that even though the name of this feature tag is sip.methods, it would be encoded into the Accept-Contact header field as just "methods"), whose value includes the method of the request. When a UA sends a SUBSCRIBE request, it is RECOMMENDED that a UA include a term in an Accept-Contact feature set with the "sip.events" feature tag, whose value includes the event package of the request. Whether these terms are placed into a new feature set, or whether they are included in each feature set, is at the discretion of the implementor. In most cases, the right effect is achieved by including a term in each feature set.
UACは、UAがサポートするメソッドとイベントパッケージの明示的な好みを表現できます。UAには、「sip.methods」機能タグを備えたAccept-contact機能セットに用語を含めることをお勧めします（ただし、この機能タグの名前はsip.methodsですが、単なる「メソッド」としてヘッダーフィールドを受け入れます）。その価値には、リクエストの方法が含まれています。UAがサブスクライブリクエストを送信する場合、UAには、「sip.events」機能タグを備えたAccept-contact機能セットに用語を含めることをお勧めします。これらの用語が新機能セットに配置されるかどうか、または各機能セットに含まれているかどうかは、実装者の裁量にあります。ほとんどの場合、各機能セットに用語を含めることにより、正しい効果が達成されます。
As an example, the following Accept-Contact header field expresses a desire to route a call to a mobile device, using feature parameters taken from [3]:
例として、次のAccept-Contactヘッダーフィールドは、[3]から取得した機能パラメーターを使用して、モバイルデバイスへの呼び出しをルーティングするという欲求を表しています。
Accept-Contact: *;mobility="mobile";methods="INVITE"
The Reject-Contact header field allows the UAC to specify that a UA should not be contacted if it matches any of the values of the header field. Each value of the Reject-Contact header field contains a "*", purely to align the syntax with guidelines for SIP extensions [12], and is parameterized by a set of feature parameters. Any UA whose capabilities match the feature set described by the feature parameters matches the value.
拒否接続ヘッダーフィールドにより、UACは、ヘッダーフィールドの値のいずれかに一致する場合、UAに接触しないでください。拒否接触ヘッダーフィールドの各値には、純粋に構文をSIP拡張機能のガイドライン[12]に合わせるために「*」が含まれており、一連の機能パラメーターによってパラメーター化されています。機能パラメーターによって記述された機能セットと一致する機能がその値と一致するhaは、値と一致します。
The Accept-Contact header field allows the UAC to specify that a UA should be contacted if it matches some or all of the values of the header field. Each value of the Accept-Contact header field contains a "*", and is parameterized by a set of feature parameters. Any UA whose capabilities match the feature set described by the feature parameters matches the value. The precise behavior depends heavily on whether the "require" and "explicit" parameters are present. When both of them are present, a proxy will only forward the request to contacts which have explicitly indicated that they support the desired feature set. Any others are discarded. As such, a UAC should only use "require" and "explicit" together when it wishes the call to fail unless a contact definitively matches. It's possible that a UA supports a desired feature, but did not indicate it in its registration. When a UAC uses both "explicit" and "require", such a contact would not be reached. As a result, this combination is often not the one a UAC will want.
Accept-Contactヘッダーフィールドにより、UACは、ヘッダーフィールドの値の一部またはすべてに一致する場合、UAに接触する必要があることを指定できます。Accept-Contactヘッダーフィールドの各値には「*」が含まれており、特徴パラメーターのセットによってパラメーター化されています。機能パラメーターによって記述された機能セットと一致する機能がその値と一致するhaは、値と一致します。正確な動作は、「必要」と「明示的な」パラメーターが存在するかどうかに大きく依存します。両方が存在する場合、プロキシは、希望する機能セットをサポートすることを明示的に示した連絡先にリクエストのみを転送します。他の人は捨てられます。そのため、UACは、連絡先が明確に一致しない限り、「必要」と「明示的」を使用する場合のみ、呼び出しが失敗する場合にのみ一緒に使用する必要があります。UAが目的の機能をサポートしている可能性がありますが、登録でそれを示していませんでした。UACが「明示的」と「要求」の両方を使用する場合、そのような接触は到達しません。その結果、この組み合わせは、UACが望むものではないことがよくあります。
When only "require" is present, it means that a contact will not be used if it doesn't match. If it does match, or if it's not known whether it's a complete match, the contact is still used. A UAC would use "require" alone when a non-matching contact is useless. This is common for services where the request simply can't be serviced without the necessary features. An example is support for specific methods or event packages. When only "require" is present, the proxy will also preferentially route the request to the UA which represents the "best" match. Here, "best" means that the UA has explicitly indicated it supports more of the desired features than any other. Note, however, that this preferential routing will never override an ordering provided by the called party. The preferential routing will only choose amongst contacts of equal q-value.
「必要」のみが存在する場合、一致しない場合は連絡先が使用されないことを意味します。一致している場合、または完全な一致であるかどうかがわからない場合でも、連絡先は使用されています。UACは、一致しない連絡先が役に立たない場合に「必要」のみを使用します。これは、リクエストが必要な機能なしでは単純にサービスを提供できないサービスで一般的です。例は、特定の方法またはイベントパッケージのサポートです。「必要」のみが存在する場合、プロキシはまた、「最高の」一致を表すUAにリクエストを優先的にルーティングします。ここで、「Best」とは、UAが他のどの機能よりも多くの希望する機能をサポートしていることを明示的に示していることを意味します。ただし、この優先ルーティングは、呼び出された当事者が提供する注文を無効にすることは決してないことに注意してください。優先ルーティングは、等しいQ値の連絡先のみを選択します。
When only "explicit" is present, it means that all contacts provided by the callee will be used. However, if the contact isn't an explicit match, it is tried last amongst all other contacts with the same q-value. The principle difference, therefore, between this configuration and the usage of both "require" and "explicit" is the fallback behavior for contacts that don't match explicitly. Here, they are tried as a last resort. If "require" is also present, they are never tried.
「明示的」のみが存在する場合、Calleeが提供するすべての連絡先が使用されることを意味します。ただし、連絡先が明示的な一致でない場合、同じQ値を持つ他のすべての連絡先の中で最後に試されます。したがって、この構成と「必要」と「明示」の両方の使用との間の主な違いは、明示的に一致しない接点のフォールバック動作です。ここでは、彼らは最後の手段として試されています。「要求」も存在する場合、それらは決して試されません。
Finally, if neither "require" nor "explicit" are present, it means that all contacts provided by the callee will be used. However, if the contact doesn't match, it is tried last amongst all other contacts with the same q-value. If it does match, the request is routed preferentially to the "best" match. This is a common configuration for preferences that, if not honored, will still allow for a successful call, and the greater the match, the better.
最後に、「必要」も「明示的」が存在しない場合、Calleeが提供するすべての連絡先が使用されることを意味します。ただし、連絡先が一致しない場合、同じQ値を持つ他のすべての連絡先の中で最後に試されます。一致する場合、リクエストは「ベスト」マッチに優先的にルーティングされます。これは、名誉ではない場合でも成功したコールを許可する好みの一般的な構成であり、試合が大きくなればなるほど、より良いものです。
When a UAS compliant to this specification receives a request whose request-URI corresponds to one of its registered contacts, it SHOULD apply the behavior described in Section 7.2 as if it were a proxy for the domain in the request-URI. The UAS acts as if its location database contains a single request target for the request-URI. That target is associated with a feature set. The feature set is the same as the one placed in the registration of the URI in the request-URI. If a UA had registered against multiple separate addresses-of-record, and the contacts registered for each had different capabilities, it will have used a different URI in each registration, so it can determine which feature set to use.
この仕様に準拠したUASが、リクエスト-URIが登録された連絡先の1つに対応するリクエストを受信する場合、セクション7.2で説明されている動作を、リクエスト-URIのドメインのプロキシであるかのように適用する必要があります。UASは、その場所データベースにリクエスト-URIの単一の要求ターゲットが含まれているかのように動作します。そのターゲットは機能セットに関連付けられています。機能セットは、Request-URIのURIの登録に配置されたものと同じです。UAが複数のレコードアドレスに対して登録されていて、それぞれに登録された連絡先に異なる機能が異なる場合、各登録で異なるURIを使用しているため、使用する機能セットを決定できます。
This processing occurs after the client authenticates and authorizes the request, but before the remainder of the general UAS processing described in Section 8.2.1 of RFC 3261.
この処理は、クライアントがリクエストを認証および承認した後に発生しますが、RFC 3261のセクション8.2.1で説明されている一般的なUAS処理の残りの前に行われます。
If, after performing this processing, there are no URI left in the target set, the UA SHOULD reject the request with a 480 response. If there is a URI remaining (there was only one to begin with), the UA proceeds with request processing as per RFC 3261.
この処理を実行した後、ターゲットセットにURIが残っていない場合、UAは480回の応答でリクエストを拒否する必要があります。URIが残っている場合（最初は1つだけでした）、UAはRFC 3261に従ってリクエスト処理に進みます。
Having a UAS perform the matching operations as if it were a proxy allows certain caller preferences to be honored, even if the proxy doesn't support the extension.
プロキシがプロキシが拡張機能をサポートしていなくても、UASがプロキシであるかのようにマッチング操作を実行することで、特定の発信者の好みを尊重することができます。
A UAS SHOULD process any queue directive present in a Request-Disposition header field in the request. All other directives MUST be ignored.
UASは、リクエスト内のリクエスト配置ヘッダーフィールドに存在するキューディレクティブを処理する必要があります。他のすべての指令は無視する必要があります。
Proxy behavior consists of two orthogonal sets of rules - one for processing the Request-Disposition header field, and one for processing the URI and feature set preferences in the Accept-Contact and Reject-Contact header fields.
プロキシの動作は、2つの直交セットのルールで構成されています。1つはリクエスト拡張ヘッダーフィールドを処理するための1つ、もう1つはAccept-contactおよびReject-ContactヘッダーフィールドのURIおよび機能セット設定を処理します。
In addition to processing these headers, a proxy MAY add one if not present, or add a value to an existing header field, as if it were a UAC. This is useful for a proxy to request processing in downstream proxies in the implementation of a feature. However, a proxy MUST NOT modify or remove an existing header field value. This is particularly important when S/MIME is used. The message signature could include the caller preferences header fields, allowing the UAS to verify that, even though proxies may have added header fields, the original caller preferences were still present.
これらのヘッダーの処理に加えて、プロキシは存在しない場合でも1つを追加したり、既存のヘッダーフィールドに値を追加したりする場合があります。これは、プロキシが機能の実装において下流のプロキシで処理を要求するのに役立ちます。ただし、プロキシは、既存のヘッダーフィールド値を変更または削除してはなりません。これは、S/MIMEを使用する場合に特に重要です。メッセージの署名には、発信者の設定ヘッダーフィールドを含めることができ、UASがヘッダーフィールドが追加されている場合でも、元の発信者の好みがまだ存在している可能性があることをUASが確認できるようにします。
If the request contains a Request-Disposition header field and it is the owner of the domain in the Request URI, the server SHOULD execute the directives as described in Section 9.1, unless it has local policy configured to direct it otherwise.
リクエストにリクエスト拡散ヘッダーフィールドが含まれており、それがリクエストURIのドメインの所有者である場合、サーバーは、特に指示するように構成されているローカルポリシーがない限り、セクション9.1で説明されているようにディレクティブを実行する必要があります。
A proxy compliant to this specification MUST NOT apply the preferences matching operation described here to a request unless it is the owner of the domain in the request URI, and accessing a location service that has capabilities associated with request targets. However, if it is the owner of the domain, and accessing a location service that has capabilities associated with request targets, it SHOULD apply the processing described in this section. Typically, this is a proxy that is using a registration database to determine the request targets. However, if a proxy knows about capabilities through some other means, it SHOULD apply the processing defined here as well. If it does perform the processing, it MUST do so as described below.
この仕様に準拠したプロキシは、Request URIのドメインの所有者であり、リクエストターゲットに関連付けられた機能を持つロケーションサービスにアクセスしない限り、ここで説明されている設定マッチング操作をリクエストに適用してはなりません。ただし、ドメインの所有者であり、リクエストターゲットに関連付けられた機能を備えたロケーションサービスにアクセスする場合は、このセクションで説明した処理を適用する必要があります。通常、これは登録データベースを使用してリクエストターゲットを決定するプロキシです。ただし、プロキシが他の手段を使用して機能について知っている場合は、ここで定義されている処理も適用する必要があります。処理を実行する場合は、以下に説明するようにする必要があります。
The processing is described through a conversion from the syntax described in this specification to RFC 2533 [2] syntax, followed by a matching operation and a sorting of resulting contact values. The usage of RFC 2533 syntax as an intermediate step is not required; it only serves as a useful tool to describe the behavior required of the proxy. A proxy can use any steps it likes, so long as the results are identical to the ones that would be achieved with the processing described here.
処理は、この仕様で説明されている構文からRFC 2533 [2]の構文への変換を通じて説明され、その後に一致する操作と結果として生じる接点値の並べ替えが続きます。中間ステップとしてのRFC 2533構文の使用は必要ありません。プロキシに必要な動作を説明するための便利なツールとしてのみ機能します。ここで説明する処理で結果が達成されたものと同一である限り、プロキシは好きな手順を使用できます。
The first step in proxy processing is to extract explicit preferences. To do that, it looks for the Accept-Contact and Reject-Contact header fields.
プロキシ処理の最初のステップは、明示的な好みを抽出することです。それを行うには、Accept-contactおよび拒否コンタクトヘッダーフィールドを探します。
For each value of those header fields, it extracts the feature parameters. These are the header field parameters whose name is "audio", "automata", "class", "duplex", "data", "control", "mobility", "description", "events", "priority", "methods", "extensions", "schemes", "application", "video", "language", "type", "isfocus", "actor", or "text", or whose name begins with a plus (+) [3]. The proxy converts all of those parameters to the syntax of RFC 2533, based on the rules in Section 8.
これらのヘッダーフィールドの各値について、機能パラメーターを抽出します。これらは、名前が「オーディオ」、「オートマトン」、「クラス」、「デュプレックス」、「データ」、「コントロール」、「モビリティ」、「説明」、「イベント」、「優先度」、「優先度」という名前のヘッダーフィールドパラメーターです。方法 "、"拡張子 "、「スキーム"、「アプリケーション」、「ビデオ」、「言語」、「タイプ」、「isfocus」、 "actor"、または "text"、またはその名前がプラス（）で始まる[）[3]。プロキシは、セクション8のルールに基づいて、これらすべてのパラメーターをRFC 2533の構文に変換します。
The result will be a set of feature set predicates in conjunctive normal form, each of which is associated with one of the two preference header fields. If there was a req-parameter associated with a header field value in the Accept-Contact header field, the feature set predicate derived from that header field value is said to have its require flag set. Similarly, if there was an explicit-param associated with a header field value in the Accept-Contact header field, the feature set predicate derived from that header field value is said to have its explicit flag set.
結果は、組織的な通常の形式で一連の機能セットの述語になり、それぞれが2つの優先ヘッダーフィールドのいずれかに関連付けられています。Accept-Tontactヘッダーフィールドにヘッダーフィールド値に関連付けられたREQパラメーターがある場合、そのヘッダーフィールド値から導出された特徴セットは、その要求フラグが設定されていると言われています。同様に、Accept-Contactヘッダーフィールドにヘッダーフィールド値に関連付けられた明示的なパラムがある場合、そのヘッダーフィールド値から導出された特徴セットは、明示的なフラグが設定されていると言われています。
If, and only if, the proxy did not find any explicit preferences in the request (because there was no Accept-Contact or Reject-Contact header field), the proxy extracts implicit preferences. These preferences are ones implied by the presence of other information in the request.
プロキシがリクエストに明示的な設定を見つけられなかった場合（受け入れコンタクトまたは拒否ヘッダーフィールドがなかったため）、プロキシは暗黙の好みを抽出します。これらの好みは、リクエストに他の情報が存在することによって暗示されるものです。
First, the proxy creates a conjunction with no terms. This conjunction represents a feature set that will be associated with the Accept-Contact header field, as if it were included there. Note that there is no modification of the message implied - only an association for the purposes of processing. Furthermore, this feature set has its require flag set, but not its explicit flag.
最初に、プロキシは条件なしの接続詞を作成します。この接続詞は、あたかもそこに含まれているかのように、Accept-Contactヘッダーフィールドに関連付けられる機能セットを表します。暗示されたメッセージの変更はないことに注意してください - 処理の目的のための協会のみ。さらに、この機能セットには要求フラグセットがありますが、明示的なフラグはありません。
The proxy then adds terms to the conjunction for the two implicit preference types below.
次に、プロキシは、以下の2つの暗黙の優先型タイプの接続詞に用語を追加します。
One implicit preference is the method. When a UAC sends a request with a specific method, it is an implicit preference to have the request routed only to UAs that support that method. To support this implicit preference, the proxy adds a term to the conjunction of the following form:
1つの暗黙の好みは方法です。UACが特定のメソッドを使用してリクエストを送信する場合、その方法をサポートするUASのみにリクエストをルーティングすることは暗黙の好みです。この暗黙の好みをサポートするために、プロキシは次の形式の接続詞に用語を追加します。
(sip.methods=[method of request])
（sip.methods = [要求の方法]）
For requests that establish a subscription [5], the Event header field is another expression of an implicit preference. It expresses a desire for the request to be routed only to a server that supports the given event package. To support this implicit preference, the proxy adds a term to the conjunction of the following form:
サブスクリプション[5]を確立するリクエストの場合、イベントヘッダーフィールドは暗黙の好みの別の式です。これは、特定のイベントパッケージをサポートするサーバーにのみルーティングされるという要求に対する欲求を表明しています。この暗黙の好みをサポートするために、プロキシは次の形式の接続詞に用語を追加します。
(sip.events=[value of the Event header field])
（sip.events = [イベントヘッダーフィールドの値]）
The proxy then takes each URI in the target set (the set of URI it is going to proxy or redirect to), and obtains its capabilities as an RFC 2533 formatted feature set predicate. This is called a contact predicate. If the target URI was obtained through a registration, the proxy computes the contact predicate by extracting the feature parameters from the Contact header field [3] and then converting them to a feature predicate. To extract the feature parameters, the proxy follows these steps:
次に、プロキシはターゲットセット（プロキシまたはリダイレクトのURIのセット）の各URIを取得し、RFC 2533フォーマットされた機能セットの述語としてその機能を取得します。これは接触述語と呼ばれます。ターゲットURIが登録を通じて取得された場合、プロキシは、接触ヘッダーフィールド[3]から特徴パラメーターを抽出し、それらを特徴述語に変換することにより、接触述語を計算します。特徴パラメーターを抽出するために、プロキシは次の手順に従います。
1. Create an initial, empty list of feature parameters.
1. 機能パラメーターの最初の空のリストを作成します。
2. If the Contact URI parameters included the "audio", "automata", "class", "duplex", "data", "control", "mobility", "description", "events", "priority", "methods", "schemes", "application", "video", "actor", "language", "isfocus", "type", "extensions", or "text" parameters, those are copied into the list.
2. 連絡先のURIパラメーターには、「オーディオ」、「オートマトン」、「クラス」、「デュプレックス」、「データ」、「コントロール」、「モビリティ」、「説明」、「イベント」、「優先度」、「メソッド」が含まれている場合、「スキーム」、「アプリケーション」、「ビデオ」、「アクター」、「言語」、「ISFOCUS」、「タイプ」、「エクステンション」、または「テキスト」パラメーターがリストにコピーされます。
3. If any Contact URI parameter name begins with a "+", it is copied into the list if the list does not already contain that name with the plus removed. In other words, if the "video" feature parameter is in the list, the "+video" parameter would not be placed into the list. This conflict should never arise if the client were compliant to [3], since it is illegal to use the + form for encoding of a feature tag in the base set.
3. Contact URIパラメーター名が「」で始まる場合、リストにその名前が削除されている場合、リストにコピーされます。つまり、「ビデオ」機能パラメーターがリストにある場合、「ビデオ」パラメーターはリストに配置されません。クライアントが[3]に準拠している場合、この競合は決して発生しません。
If the URI in the target set had no feature parameters, it is said to be immune to caller preference processing. This means that the URI is removed from the target set temporarily, the caller preferences processing described below is executed, and then the URI is added back in.
ターゲットセットのURIに特徴パラメーターがなかった場合、発信者の好みの処理に免疫があると言われています。これは、URIがターゲットセットから一時的に削除され、以下に説明する発信者設定処理が実行され、URIが再び追加されることを意味します。
Assuming the URI has feature parameters, they are converted to RFC 2533 syntax using the rules of Section 8.
URIに特徴パラメーターがあると仮定すると、セクション8のルールを使用してRFC 2533構文に変換されます。
The resulting predicate is associated with a q-value. If the contact predicate was learned through a REGISTER request, the q-value is equal to the q-value in the Contact header field parameter, else "1.0" if not specified.
結果の述語は、Q値に関連付けられています。連絡先の述語がレジスタリクエストを介して学習された場合、Q値は、接触ヘッダーフィールドパラメーターのQ値に等しく、特定されていない場合は「1.0」に等しくなります。
As an example, consider the following registered Contact header field:
例として、次の登録された連絡先ヘッダーフィールドを検討してください。
Contact: <sip:user@example.com>;audio;video;mobility="fixed";
+sip.message="TRUE";other-param=66372;
methods="INVITE,OPTIONS,BYE,CANCEL,ACK";schemes="sip,http"
This would be converted into the following predicate:
これは次の述語に変換されます。
(& (sip.audio=TRUE)
(sip.video=TRUE)
(sip.mobility=fixed)
(sip.message=TRUE)
(| (sip.methods=INVITE) (sip.methods=OPTIONS) (sip.methods=BYE)
(sip.methods=CANCEL) (sip.methods=ACK))
(| (sip.schemes=sip) (sip.schemes=http)))
Note that "other-param" was not considered a feature parameter, since it is neither a base tag nor did it begin with a leading +.
「他のパラム」は、ベースタグでもリーディングでも始まったものでもないため、機能パラメーターとは見なされなかったことに注意してください。
It is important to note that the proxy does not have to know anything about the meaning of the feature tags that it is comparing in order to perform the matching operation. The rules for performing the comparison depend on syntactic hints present in the values of each feature tag. For example, a predicate such as:
一致する操作を実行するために比較している機能タグの意味について、プロキシは何も知る必要がないことに注意することが重要です。比較を実行するためのルールは、各機能タグの値に存在する構文のヒントに依存します。たとえば、次のような述語
(foo>=4)
（foo> = 4）
implies that the feature tag "foo" is a numeric value. The matching rules in RFC 2533 only require an implementation to know whether the feature tag is a numeric, token, or quoted string (booleans can be treated as tokens). Quoted strings are always matched using a case-sensitive matching operation. Tokens are matched using case-insensitive matching. These two cases are differentiated by the presence of angle brackets around the feature tag value. When these brackets are present (i.e., ;+sip.foo="<value>"), it implies case sensitive string comparison. When they are not present, (i.e., (;+sip.bar="val"), it implies case insensitivity. Numerics are matched using normal mathematical comparisons.
機能タグ「Foo」が数値であることを意味します。RFC 2533の一致するルールは、機能タグが数値、トークン、または引用文字列であるかどうかを知るための実装のみを必要とします（ブール人はトークンとして扱うことができます）。引用された文字列は、ケースに敏感なマッチング操作を使用して常に一致します。トークンは、ケースに依存しないマッチングを使用して一致します。これらの2つのケースは、機能タグ値の周りの角度ブラケットの存在によって区別されます。これらのブラケットが存在する場合（つまり、; sip.foo = "<balue>"）、それはケースに敏感な文字列比較を意味します。それらが存在しない場合（つまり、（; sip.bar = "val"）、それは症例の無感覚を意味します。数値は通常の数学的比較を使用して一致します。
First, the proxy applies the predicates associated with the Reject-Contact header field.
まず、プロキシは、拒否コンタクトヘッダーフィールドに関連付けられた述語を適用します。
For each contact predicate, each Reject-Contact predicate (that is, each predicate associated with the Reject-Contact header field) is examined. If that Reject-Contact predicate contains a filter for a feature tag, and that feature tag is not present anywhere in the contact predicate, that Reject-Contact predicate is discarded for the processing of that contact predicate. If the Reject-Contact predicate is not discarded, it is matched with the contact predicate using the matching operation of RFC 2533 [2]. If the result is a match, the URI corresponding to that contact predicate is discarded from the target set.
各接触述語について、それぞれの拒否接触述語（つまり、拒否接触ヘッダーフィールドに関連する各述語）を調べます。その拒否コンタクトの述語に機能タグのフィルターが含まれており、その機能タグが連絡先述語のどこにも存在しない場合、拒否コンタクト述語はその接点述語の処理のために破棄されます。拒絶接合の述語が破棄されない場合、RFC 2533の一致操作を使用して、接触述語と一致します[2]。結果が一致している場合、その接触に対応するURIはターゲットセットから破棄されます。
The result is that Reject-Contact will only discard URIs where the UA has explicitly indicated support for the features that are not wanted.
その結果、拒否コンタクトは、UAが望まれていない機能のサポートを明示的に示している場合にのみURIを破棄します。
Next, the proxy applies the predicates associated with the Accept-Contact header field. For each contact that remains in the target set, the proxy constructs a matching set, Ms. Initially, this set contains all of the Accept-Contact predicates. Each of those predicates is examined. It is matched with the contact predicate using the matching operation of RFC 2533 [2]. If the result is not a match, and the Accept-Contact predicate had its require flag set, the URI corresponding to that contact predicate is discarded from the target set. If the result is not a match, but the Accept-Contact predicate did not have its require flag set, that contact URI is not discarded from the target set, however, the Accept-Contact predicate is removed from the matching set for that contact.
次に、プロキシは、Accept-Contactヘッダーフィールドに関連付けられた述語を適用します。ターゲットセットに残っている各連絡先について、プロキシは一致するセットを構築します。最初は、このセットにはすべてのAccept-Contact Prendicatesが含まれています。これらの述語のそれぞれが調べられます。RFC 2533 [2]のマッチング操作を使用して、接触述語と一致します。結果が一致しておらず、Accept-contact Predicateにその要求フラグセットがあった場合、その接触に対応するURIはターゲットセットから破棄されます。結果が一致していないが、Accept-Contactの述語に要求フラグセットがなかった場合、その接触URIはターゲットセットから廃棄されませんが、その接点の一致セットからAccept-Contact Predicateは削除されます。
For each contact that remains in the target set, the proxy computes a score for that contact against each predicate in the contact's matching set. Let the number of terms in the Accept-Contact predicate conjunction be equal to N. Each term in that predicate contains a single feature tag. If the contact predicate has a term containing that same feature tag, the score is incremented by 1/N. If the feature tag was not present in the contact predicate, the score remains unchanged. Based on these rules, the score can range between zero and one.
ターゲットセットに残っている各連絡先について、プロキシは、連絡先のマッチングセットの各述語に対してその連絡先のスコアを計算します。Accept-Contact Presticate接続詞の用語数をNに等しくします。そのPredicateの各用語には、単一の機能タグが含まれています。連絡先のPredicateに同じ機能タグを含む用語がある場合、スコアは1/nで増加します。機能タグが連絡先の述語に存在しなかった場合、スコアは変更されていません。これらのルールに基づいて、スコアはゼロから1つの範囲です。
T
+----------> DROP Contact
|
|
/ \
/ \
T / \ F
+---->/require\------> Set score=0
| \ /
| \ /
/ \ \ /
/ \ \/
score<1 / \
+-------> /explicit----> Score unchanged
| \ / F
| \ /
/ \ \ /
/ \ \/
+--------+ / \
-->|Compute |--> /Score \ --------> Score unchanged
| Score | \ / score=1
+--------+ \ /
\ /
\/
Figure 1: Applying the Score
図1：スコアの適用
The require and explicit tags are then applied, resulting in potential modification of the score and the target set. This process is summarized in Figure 1. If the score for the contact predicate against that Accept-Contact predicate was less than one, the Accept-Contact predicate had an explicit tag, and if the predicate also had a require tag, the Contact URI corresponding to that contact predicate is dropped. If, however, the predicate did not have a require tag, the score is set to zero. If there was no explicit tag, the score is unchanged.
その後、要求と明示的なタグが適用され、スコアとターゲットセットが潜在的に変更されます。このプロセスを図1にまとめます。そのAccept-contact述語に対する接触述語のスコアが1未満の場合、Accept-contact Presticateには明示的なタグがあり、述語にも必要なタグがある場合、連絡先URIに対応する接点URIに対応します。その連絡先は述語がドロップされます。ただし、述語に必要なタグがない場合、スコアはゼロに設定されます。明示的なタグがなかった場合、スコアは変更されていません。
The next step is to combine the scores and the q-values associated with the predicates in the matching set, to arrive at an overall caller preference, Qa. For those URIs in the target set which remain, there will be a score which indicates its match against each Accept-Contact predicate in the matching set. If there are M Accept-Contact predicates in the matching set, there will be M scores S1 through SM, for each contact. The overall caller preference, Qa, is the arithmetic average of S1 through SM.
次のステップは、マッチングセットの述語に関連付けられたスコアとQ値を組み合わせて、全体的な発信者の好みQAに到達することです。残っているターゲットセットのurisの場合、マッチングセットの各受容コンタクト述語に対する一致を示すスコアがあります。マッチングセットにM Accept-Contactの述語がある場合、各接触に対してMスコアS1からSMからSMがあります。全体的な発信者の好みQAは、SMからSMの算術平均です。
At this point, any URIs that were removed from the target set because they were immune from caller preferences are added back in, and Qa for that URI is set to 1.0.
この時点で、発信者の好みから免疫があったためにターゲットセットから削除されたURIは戻っており、そのURIのQAは1.0に設定されています。
The purpose of the caller preference Qa is to provide an ordering for any contacts remaining in the target set, if the callee has not provided an ordering. To do this, the contacts remaining in the target set are sorted by the q-value provided by the callee. Once sorted, they are grouped into equivalence classes, such that all contacts with the same q-value are in the same equivalence class. Within each equivalence class, the contacts are then ordered based on their values of Qa. The result is an ordered list of contacts that is used by the proxy.
Calleeが注文を提供していない場合、発信者の好みのQAの目的は、ターゲットセットに残っている連絡先の注文を提供することです。これを行うために、ターゲットセットに残っている連絡先は、Calleeが提供するQ値によってソートされます。ソートすると、同じQ値を持つすべての接触が同じ等価クラスになるように、それらは同等のクラスにグループ化されます。各等価クラス内で、連絡先はQAの値に基づいて順序付けられます。結果は、プロキシで使用される連絡先の順序付けられたリストです。
If there were no URIs in the target set after the application of the processing in this section, and the caller preferences were based on implicit preferences (Section 7.2.2), the processing in this section is discarded, and the original target set, ordered by their original q-values, is used.
このセクションで処理の適用後にターゲットセットにURIがなかった場合、発信者の好みが暗黙の設定に基づいている場合（セクション7.2.2）、このセクションの処理は破棄され、元のターゲットセットが順序付けられています。元のQ値によって使用されます。
This handles the case where implicit preferences for the method or event packages resulted in the elimination of all potential targets. By going back to the original target set, those URIs will be tried, and result in the generation of a 405 or 489 response. The UAC can then use this information to try again, or report the error to the user. Without reverting to the original target set, the UAC would see a 480 response, and have no knowledge of why their request failed. Of course, the target set can also be empty after the application of explicit preferences. This will result in the generation of a 480 by the proxy. This behavior is acceptable, and indeed, desirable in the case of explicit preferences. When the caller makes an explicit preference, it is agreeing that its request might fail because of a preference mismatch. One might try to return an error indicating the capabilities of the callee, so that the caller could perhaps try again. However, doing so results in the leaking of potentially sensitive information to the caller without authorization from the callee, and therefore this specification does not provide a means for it.
これにより、メソッドパッケージまたはイベントパッケージに対する暗黙の好みが、すべての潜在的なターゲットが排除される場合を処理します。元のターゲットセットに戻ることにより、これらのURIが試され、405または489の応答が生成されます。UACは、この情報を使用して再試行するか、ユーザーにエラーを報告することができます。元のターゲットセットに戻ることなく、UACには480の応答が表示され、リクエストが失敗した理由について知識がありません。もちろん、ターゲットセットは、明示的な設定を適用した後も空にすることもあります。これにより、プロキシによる480の生成が行われます。この動作は受け入れられ、実際、明示的な好みの場合に望ましいです。発信者が明示的な好みを行うと、好みの不一致のためにその要求が失敗する可能性があることに同意しています。発信者がおそらく再試行できるように、Calleeの機能を示すエラーを返しようとするかもしれません。ただし、そうすることで、Calleeからの許可なしに発信者に潜在的に機密情報が漏れているため、この仕様はそれの手段を提供しません。
If a proxy server is recursing, it adds the Contact header fields returned in the redirect responses to the target set, and re-applies the caller preferences algorithm.
プロキシサーバーが再発している場合、ターゲットセットへのリダイレクト応答で返された連絡先ヘッダーフィールドを追加し、発信者設定アルゴリズムを再適用します。
If the server is redirecting, it returns all entries in the target set. It assigns q-values to those entries so that the ordering is identical to the ordering determined by the processing above. However, it MUST NOT include the feature parameters for the entries in the target set. If it did, the upstream proxy server would apply the same caller preferences once more, resulting in a double application of those preferences. If the redirect server does wish to include the feature parameters in the Contact header field, it MUST redirect using the original target set and original q-values, before the application of caller preferences.
サーバーがリダイレクトしている場合、ターゲットセットのすべてのエントリを返します。Q値をそれらのエントリに割り当て、順序は上記の処理によって決定される順序と同一になるようにします。ただし、ターゲットセットのエントリの機能パラメーターを含めてはなりません。もしそうなら、上流のプロキシサーバーは同じ発信者の設定をもう一度適用し、それらの設定を二重に適用します。リダイレクトサーバーが接触ヘッダーフィールドに機能パラメーターを含めることを希望する場合、発信者の設定を適用する前に、元のターゲットセットと元のQ値を使用してリダイレクトする必要があります。
Consider the following example, which is contrived but illustrative of the various components of the matching process. There are five registered Contacts for sip:user@example.com. They are:
次の例を考えてみましょう。これは考え直されていますが、一致するプロセスのさまざまなコンポーネントを示しています。sipには5つの登録連絡先があります：user@example.com。彼らです：
Contact: sip:u1@h.example.com;audio;video;methods="INVITE,BYE";q=0.2
Contact: sip:u2@h.example.com;audio="FALSE";
methods="INVITE";actor="msg-taker";q=0.2
Contact: sip:u3@h.example.com;audio;actor="msg-taker";
methods="INVITE";video;q=0.3
Contact: sip:u4@h.example.com;audio;methods="INVITE,OPTIONS";q=0.2
Contact: sip:u5@h.example.com;q=0.5
An INVITE sent to sip:user@example.com contained the following caller preferences header fields:
sipに送信された招待状：user@example.comには、次の発信者設定ヘッダーフィールドが含まれていました。
Reject-Contact: *;actor="msg-taker";video
Accept-Contact: *;audio;require
Accept-Contact: *;video;explicit
Accept-Contact: *;methods="BYE";class="business";q=1.0
There are no implicit preferences in this example, because explicit preferences are provided.
この例には、明示的な好みが提供されるため、暗黙の設定はありません。
The proxy first removes u5 from the target set, since it is immune from caller preferences processing.
プロキシは、発信者の設定処理から免疫がないため、ターゲットセットからU5を削除します。
Next, the proxy processes the Reject-Contact header field. It is a match for all four remaining contacts, but only an explicit match for u3. That is because u3 is the only one that explicitly indicated support for video, and explicitly indicated it is a message taker. So, u3 gets discarded, and the others remain.
次に、プロキシは拒否コンタクトヘッダーフィールドを処理します。残りの4つの連絡先すべてにマッチしますが、U3の明示的な一致のみです。それは、U3がビデオのサポートを明示的に示した唯一のものであり、それがメッセージテイカーであることを明示的に示したためです。したがって、U3は破棄され、他のものは残ります。
Next, each of the remaining three contacts is compared against each of the three Accept-Contact predicates. u1 is a match to all three, earning a score of 1.0 for the first two predicates, and 0.5 for the third (the methods feature tag was present in the contact predicate, but the class tag was not). u2 doesn't match the first predicate. Because that predicate has a require tag, u2 is discarded. u4 matches the first predicate, earning a score of 1.0. u4 matches the second predicate, but since the match is not explicit (the score is 0.0, in fact), the score is set to zero (it was already zero, so nothing changes). u4 does not match the third predicate.
次に、残りの3つの連絡先のそれぞれが、3つのAccept-Contact述語のそれぞれと比較されます。U1は3つすべてと一致し、最初の2つの述語で1.0のスコアを獲得し、3番目で0.5を獲得しました（接触述語にはメソッド機能タグが存在しましたが、クラスタグはそうではありませんでした）。U2は最初の述語と一致しません。その述語には必要なタグがあるため、U2は破棄されます。U4は最初の述語と一致し、1.0のスコアを獲得します。U4は2番目の述語と一致しますが、試合は明示的ではないため（実際、スコアは0.0です）、スコアはゼロに設定されています（すでにゼロであるため、変更はありません）。U4は3番目の述語と一致しません。
At this point, u1 and u4 remain. u1 matched all three Accept-Contact predicates, so its matching set contains all three, with scores of 1, 1, and 0.5. u4 matches the first two predicates, with scores of 1.0 and 0.0. Qa for u1 is 0.83 and Qa for u4 is 0.5. u5 is added back in with a Qa of 1.0.
この時点で、U1とU4は残ります。U1は3つのAccept-Contact Prendicatesすべてを一致させたため、一致するセットには3つすべてが含まれ、1、1、および0.5のスコアが含まれています。U4は最初の2つの述語と一致し、スコアは1.0と0.0です。U1のQAは0.83、U4のQAは0.5です。U5は1.0のQAで再び追加されます。
Next, the remaining contacts in the target set are sorted by q-value. u5 has a value of 0.5, u1 has a q-value of 0.2 and so does u4. There are two equivalence classes. The first has a q-value of 0.5, and consists of just u5. Since there is only one member of the class, sorting within the class has no impact. The second equivalence class has a q-value of 0.2. Within that class, the two contacts, u1 and u4, are ordered based on their values of Qa. u1 has a Qa of 0.83, and u4, a Qa of 0.5. Thus, u1 comes first, followed by u4. The resulting overall ordered set of contacts in the target set is u5, u1, and then u4.
次に、ターゲットセットの残りの連絡先はQ値によってソートされます。U5の値は0.5、U1のQ値は0.2で、U4も同様です。2つの等価クラスがあります。1つ目は0.5のQ値を持ち、U5だけで構成されています。クラスには1人のメンバーしかないため、クラス内のソートは影響を与えません。2番目の等価クラスのQ値は0.2です。そのクラス内で、2つの連絡先、U1とU4はQAの値に基づいて順序付けられます。U1のQAは0.83、U4は0.5です。したがって、U1が最初に登場し、続いてU4が続きます。ターゲットセットの全体的な順序付けられた連絡先セットは、U5、U1、およびU4です。
Mapping between feature parameters and a feature set predicate, formatted according to the syntax of RFC 2533 [2], is trivial. It is just the opposite of the process described in Section 5 of [3].
RFC 2533 [2]の構文に従ってフォーマットされた、機能パラメーターと機能セットの述語間のマッピングは些細なことです。これは、[3]のセクション5で説明されているプロセスの正反対です。
Starting from a set of feature-param, the procedure is as follows. Construct a conjunction. Each term in the conjunction derives from one feature-param. If the feature-param has no value, it is equivalent, in terms of the processing which follows, as if it had a value of "TRUE".
特徴パラムのセットから始めて、手順は次のとおりです。接続詞を作成します。接続詞の各用語は、1つの機能パラムから派生します。機能パラムに値がない場合、「真」の値があるかのように、それが続く処理の観点から同等です。
If the feature-param value is a tag-value-list, the element of the conjunction is a disjunction. There is one term in the disjunction for each tag-value in the tag-value-list.
機能パラム値がタグ値リストである場合、接続詞の要素は分離です。タグ値リストの各タグ値の分離には1つの用語があります。
Consider now the construction of a filter from a tag-value. If the tag-value starts with an exclamation mark (!), the filter is of the form:
これで、タグ値からフィルターの構築を検討してください。タグ値が感嘆符（！）で始まる場合、フィルターは次の形式です。
(! <filter from remainder>)
where "<filter from remainder>" refers to the filter that would be constructed from the tag-value if the exclamation mark had not been present.
ここで、感嘆符が存在していなかった場合、「lest From Lester>」とは、タグ値から構築されるフィルターを指します。
If the tag-value starts with an octothorpe (#), the filter is a numeric comparison. The comparator is either =, >=, <=, or a range based on the next characters in the phrase. If the next characters are =, >=, or <=, the filter is of the form:
タグ値がOctothorpe（＃）で始まる場合、フィルターは数値比較です。コンパレータは、=、> =、<=、またはフレーズの次の文字に基づく範囲のいずれかです。次の文字が=、> =、または<=の場合、フィルターはフォームです。
(name comparator compare-value)
（名前Comparator Compare-Value）
where name is the name of the feature parameter after it has been decoded (see below), and the comparator is either =, >=, or <= depending of the initial characters in the phrase. If the remainder of the text in the tag-value after the equal contains a decimal point (implying a rational number), the decimal point is shifted right N times until it is an integer, I. Compare-value above is then set to "I / 10**N", where 10**N is the result of computing the number 10 to the Nth power.
ここで、名前は機能パラメーターの名前がデコードされた後（以下を参照）、コンパレータはフレーズの初期文字に応じて=、> =、または<=のいずれかです。等量が小数点を含む後のタグ値の残りのテキスト（合理的な数を暗示する）が含まれている場合、小数点は整数になるまで右n回転します。i / 10 ** n "、ここで、10 ** nは数10をnth電力に計算した結果です。
If the value after the octothorpe is a number, the filter is a range. The format of the filter is:
Octothorpeの後の値が数字の場合、フィルターは範囲です。フィルターの形式は次のとおりです。
(name=<remainder>)
where "name" is the feature-tag after it has been decoded (see below), and "<remainder>" is the remainder of the text in the tag-value after the #, with any decimal numbers converted to a rational form, and the colon replaced by a double dot (..).
ここで、「名前」はデコードされた後の機能タグ（以下を参照）、および「<rester>」は＃後のタグ値の残りのテキストであり、10進数は合理的な形式に変換されます。コロンは二重ドット（..）に置き換えられました。
If the tag-value does not begin with an octothorpe (it is a token-nobang or boolean), the filter is of the form:
タグ値がOctothorpe（Token-nobangまたはboolean）で始まっていない場合、フィルターは次の形式です。
(name=tag-value)
（name = tag-value）
where name is the feature-tag after it has been decoded (see below).
ここで、名前は機能タグがデコードされた後です（以下を参照）。
If the feature-param contains a string-value (based on the fact that it begins with a left angle bracket ("<") and ends with a right angle bracket (">")), the filter is of the form:
特徴パラムに文字列値が含まれている場合（左角度ブラケット（ "<"）で始まり、直角ブラケット（ ">"）で終わるという事実に基づいています）、フィルターは次の形式です。
(name="qdtext")
（name = "qdtext"）
Note the explicit usage of quotes around the qdtext, which indicate that the value is a string. In RFC 2533, strings are compared using case sensitive rules, and tokens are compared using case insensitive rules.
QDTextの周りの引用の明示的な使用法に注意してください。これは、値が文字列であることを示しています。RFC 2533では、ケースに敏感なルールを使用して文字列が比較され、トークンはケースの非感受性ルールを使用して比較されます。
Feature tags, as specified in RFC 2506 [13], cannot be directly represented as header field parameters in the Contact, Accept-Contact, and Reject-Contact header fields. This is due to an inconsistency in the grammars, and in the need to differentiate feature parameters from parameters used by other extensions. As such, feature tag values are encoded from RFC 2506 format to yield an enc-feature-tag, and then are decoded into RFC 2506 format. The decoding process is simple. If there is a leading plus (+) sign, it is removed. Any exclamation point (!) is converted to a colon (:) and any single quote (') is converted to a forward slash (/). If there was no leading plus sign, and the remainder of the encoded name was "audio", "automata", "class", "duplex", "data", "control", "mobility", "description", "events", "priority", "methods", "schemes", "application", "video", "actor", "isfocus", "extensions" or "text", the prefix "sip." is added to the remainder of the encoded name to compute the feature tag name.
RFC 2506 [13]で指定されている機能タグは、接触、受け入れ、および拒否ヘッダーフィールドのヘッダーフィールドパラメーターとして直接表現することはできません。これは、文法の矛盾と、他の拡張機能で使用されるパラメーターと特徴パラメーターを区別する必要があるためです。そのため、機能タグの値はRFC 2506形式からエンコードされて、エンクフェアチュアタグを生成し、RFC 2506形式にデコードされます。デコードプロセスは簡単です。主要なPlus（）サインがある場合、削除されます。感嘆符（！）はコロン（:)に変換され、単一の引用（ '）はフォワードスラッシュ（/）に変換されます。リーディングプラスサインがなく、エンコードされた名前の残りは「オーディオ」、「オートマトン」、「クラス」、「デュプレックス」、「データ」、「コントロール」、「モビリティ」、「説明」、「説明」でした。「、「優先度」、「メソッド」、「スキーム」、「アプリケーション」、「ビデオ」、「アクター」、「イスフォカス」、「拡張機能」または「テキスト」、プレフィックス「SIP」。エンコードされた名前の残りの部分に追加され、機能タグ名を計算します。
As an example, the Accept-Contact header field:
例として、Accept-Contactヘッダーフィールド：
Accept-Contact:*;mobility="fixed"
;events="!presence,message-summary"
;language="en,de";description="<PC>";+sip.newparam
;+rangeparam="#-4:+5.125"
would be converted to the following 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))
This specification defines three new header fields - Accept-Contact, Reject-Contact, and Request-Disposition.
この仕様では、3つの新しいヘッダーフィールドが定義されています。これは、受け入れ、接触、拒否コンタクト、およびリクエスト配置です。
Figure 2 and Figure 3 are an extension of Tables 2 and 3 in RFC 3261 [1] for the Accept-Contact, Reject-Contact, and Request-Disposition header fields. The column "INF" is for the INFO method [6], "PRA" is for the PRACK method [7], "UPD" is for the UPDATE method [8], "SUB" is for the SUBSCRIBE method [5], "NOT" is for the NOTIFY method [5], "MSG" is for the MESSAGE method [9], and "REF" is for the REFER method [10].
図2と図3は、受け入れコンタクト、拒否コンタクト、およびリクエスト拡散ヘッダーフィールドのRFC 3261 [1]の表2および3の拡張です。列「inf」は情報方法[6]用、「pra」はprackメソッド[7]用です。「upd」は更新方法[8]、「sub」はサブスクライブメソッド[5]用です。「NOT」はNotify Method [5]のためのものであり、「MSG」はメッセージメソッド[9]用であり、「REF」は参照方法[10]用です。
Header field where proxy ACK BYE CAN INV OPT REG
プロキシACK ByeがregをINVするヘッダーフィールド
Accept-Contact R ar o o o o o -
Reject-Contact R ar o o o o o -
Request-Disposition R ar o o o o o o
Figure 2: Accept-Contact, Reject-Contact, and Request-Disposition header fields
図2：コンタクト、拒否コンタクト、リクエスト拡散ヘッダーフィールドを受け入れる
Header field where proxy PRA UPD SUB NOT INF MSG REF
プロキシPRA UPD SUB NOT INFSMSG REFを使用するヘッダーフィールド
Accept-Contact R ar o o o o o o o
Reject-Contact R ar o o o o o o o
Request-Disposition R ar o o o o o o o
Figure 3: Accept-Contact, Reject-Contact, and Request-Disposition header fields
図3：コンタクト、拒否コンタクト、リクエスト拡散ヘッダーフィールドを受け入れる
The Request-Disposition header field specifies caller preferences for how a server should process a request. Its value is a list of tokens, each of which specifies a particular directive. Its syntax is specified in Section 10. Note that a compact form, using the letter d, has been defined. The directives are grouped into types. There can only be one directive of each type per request (e.g., you cannot have both "proxy" and "redirect" in the same Request-Disposition header field).
リクエスト拡張ヘッダーフィールドは、サーバーがリクエストを処理する方法に対する発信者の設定を指定します。その値はトークンのリストであり、それぞれが特定の指令を指定します。その構文はセクション10で指定されています。文字dを使用したコンパクトなフォームが定義されていることに注意してください。ディレクティブはタイプにグループ化されます。要求ごとに各タイプの指令は1つだけです（たとえば、同じリクエスト配置ヘッダーフィールドに「プロキシ」と「リダイレクト」の両方を使用することはできません）。
When the caller specifies a directive, the server SHOULD honor that directive.
発信者が指令を指定する場合、サーバーはその指令を尊重する必要があります。
The following types of directives are defined:
次のタイプの指令が定義されています。
proxy-directive: This type of directive indicates whether the caller would like each server to proxy ("proxy") or redirect ("redirect").
プロキシ指向性：このタイプの指令は、発信者が各サーバーをプロキシ（「プロキシ」）またはリダイレクト（「リダイレクト」）に希望するかどうかを示します。
cancel-directive: This type of directive indicates whether the caller would like each proxy server to send a CANCEL request downstream ("cancel") in response to a 200 OK from the downstream server (which is the normal mode of operation, making it redundant), or whether this function should be left to the caller ("no-cancel"). If a proxy receives a request with this parameter set to "no-cancel", it SHOULD NOT CANCEL any outstanding branches upon receipt of a 2xx. However, it would still send CANCEL on any outstanding branches upon receipt of a 6xx.
CANCEL-DIRECTIVE：このタイプのディレクティブは、発信者が各プロキシサーバーにキャンセルリクエストをダウンストリーム（「キャンセル」）に送信したいかどうかを示します。）、またはこの関数を発信者に任せるべきかどうか（ "Nocancel"）。プロキシがこのパラメーターを「キャンセルなし」に設定してリクエストを受信した場合、2xxを受け取ったときに未解決のブランチをキャンセルしないでください。ただし、6xxを受け取ったときに、顕著な支店でキャンセルを送信します。
fork-directive: This type of directive indicates whether a proxy should fork a request ("fork"), or proxy to only a single address ("no-fork"). If the server is requested not to fork, the server SHOULD proxy the request to the "best" address (generally the one with the highest q-value). If there are multiple addresses with the highest q-value, the server chooses one based on its local policy. The directive is ignored if "redirect" has been requested.
Fork-Directive：このタイプの指令は、プロキシがリクエスト（「フォーク」）をフォークするか、単一のアドレス（「ノーフォーク」）のみにプロキシが必要かを示します。サーバーがフォークしないように要求されている場合、サーバーは「最適な」アドレス（通常、Q値が最も高いもの）にリクエストをプロキシする必要があります。Q値が最も高い複数のアドレスがある場合、サーバーはローカルポリシーに基づいて1つを選択します。「リダイレクト」が要求されている場合、指令は無視されます。
recurse-directive: This type of directive indicates whether a proxy server receiving a 3xx response should send requests to the addresses listed in the response ("recurse"), or forward the list of addresses upstream towards the caller ("no-recurse"). The directive is ignored if "redirect" has been requested.
再監督：このタイプの指令は、3XX応答を受信するプロキシサーバーが応答にリストされているアドレスにリクエストを送信するか（「再発」）、または呼び出し元に上流のアドレスのリストを転送するか（ "no-recurse"）かどうかを示します。。「リダイレクト」が要求されている場合、指令は無視されます。
parallel-directive: For a forking proxy server, this type of directive indicates whether the caller would like the proxy server to proxy the request to all known addresses at once ("parallel"), or go through them sequentially, contacting the next address only after it has received a non-2xx or non-6xx final response for the previous one ("sequential"). The directive is ignored if "redirect" has been requested.
並列指向性：フォーキングプロキシサーバーの場合、このタイプの指令は、発信者がプロキシサーバーにすべての既知のアドレスへのリクエストを一度にプロキシ（「パラレル」）にプロキシするか、次のアドレスのみに連絡するかどうかを示します。以前のものに対して非2XXまたは6XX以外の最終応答を受け取った後（「シーケンシャル」）。「リダイレクト」が要求されている場合、指令は無視されます。
queue-directive: If the called party is temporarily unreachable, e.g., because it is in another call, the caller can indicate that it wants to have its call queued ("queue") or rejected immediately ("no-queue"). If the call is queued, the server returns "182 Queued". A queued call can be terminated as described in [1].
キューディレクト：呼び出された当事者が一時的に到達不可能である場合、たとえば、別の呼び出しにあるため、発信者は、コールキュー（「キュー」）または拒否（「no-queue」）を拒否したいことを示すことができます。呼び出しがキューになった場合、サーバーは「182キュー」を返します。[1]で説明されているように、キューに留められた呼び出しを終了できます。
Example:
例：
Request-Disposition: proxy, recurse, parallel
リクエスト拡張：プロキシ、再発、並列
The set of request disposition directives is not extensible on purpose. This is to avoid a proliferation of new extensions to SIP that are "tunneled" through this header field.
リクエスト処分指令のセットは、意図的に拡張できません。これは、このヘッダーフィールドを通して「トンネル」されたSIPへの新しい拡張機能の急増を避けるためです。
The syntax for these header fields is described in Section 10. A compact form, with the letter a, has been defined for the Accept-Contact header field, and with the letter j for the Reject-Contact header field.
これらのヘッダーフィールドの構文については、セクション10で説明されています。文字aを使用したコンパクトな形式は、受け入れ接触ヘッダーフィールドで定義されており、拒否コンタクトヘッダーフィールドの文字Jが定義されています。
The BNF for the Request-Disposition header field is:
リクエスト閉鎖ヘッダーフィールドのBNFは次のとおりです。
Request-Disposition = ( "Request-Disposition" / "d" ) HCOLON
directive *(COMMA directive)
directive = proxy-directive / cancel-directive /
fork-directive / recurse-directive /
parallel-directive / queue-directive
proxy-directive = "proxy" / "redirect"
cancel-directive = "cancel" / "no-cancel"
fork-directive = "fork" / "no-fork"
recurse-directive = "recurse" / "no-recurse"
parallel-directive = "parallel" / "sequential"
queue-directive = "queue" / "no-queue"
The BNF for the Accept-Contact and Reject-Contact header fields is:
Accept-Contactおよび拒否コンタクトヘッダーフィールドのBNFは次のとおりです。
Accept-Contact = ("Accept-Contact" / "a") HCOLON ac-value
*(COMMA ac-value)
Reject-Contact = ("Reject-Contact" / "j") HCOLON rc-value
*(COMMA rc-value)
ac-value = "*" *(SEMI ac-params)
rc-value = "*" *(SEMI rc-params)
ac-params = feature-param / req-param
/ explicit-param / generic-param
;;feature param from RFC 3840
;;generic-param from RFC 3261
rc-params = feature-param / generic-param
req-param = "require"
explicit-param = "explicit"
Despite the BNF, there MUST NOT be more than one req-param or explicit-param in an ac-params. Furthermore, there can only be one instance of any feature tag in feature-param.
BNFにもかかわらず、AC-ParamsにはReq-Paramまたは明示的なパラムが1つ以上ないはずです。さらに、Feature-Paramには任意の機能タグのインスタンスが1つしかありません。
The presence of caller preferences in a request has an effect on the ways in which the request is handled at a server. As a result, requests with caller preferences SHOULD be integrity-protected with the sips mechanism specified in RFC 3261, Section 26.
リクエストにおける発信者の好みの存在は、リクエストがサーバーで処理される方法に影響を与えます。その結果、発信者の設定でのリクエストは、RFC 3261、セクション26で指定されたSIPSメカニズムで整合性を保護する必要があります。
Processing of caller preferences requires set operations and searches which can require some amount of computation. This enables a DOS attack whereby a user can send requests with substantial numbers of caller preferences, in the hopes of overloading the server. To counter this, servers SHOULD reject requests with too many rules. A reasonable number is around 20.
発信者設定の処理には、ある程度の計算が必要な設定操作と検索が必要です。これにより、ユーザーがサーバーに過負荷をかけることを期待して、かなりの数の発信者設定でリクエストを送信できるDOS攻撃が可能になります。これに対抗するために、サーバーはあまりにも多くのルールでリクエストを拒否する必要があります。妥当な数は約20です。
This specification registers three new SIP header fields, according to the process of RFC 3261 [1].
この仕様は、RFC 3261 [1]のプロセスに従って、3つの新しいSIPヘッダーフィールドを登録します。
The following is the registration for the Accept-Contact header field:
以下は、Accept-Contactヘッダーフィールドの登録です。
RFC Number: RFC 3841
RFC番号：RFC 3841
Header Field Name: Accept-Contact
ヘッダーフィールド名：Accept-Contact
Compact Form: a
コンパクトフォーム：a
The following is the registration for the Reject-Contact header field:
以下は、拒否コンタクトヘッダーフィールドの登録です。
RFC Number: RFC 3841
RFC番号：RFC 3841
Header Field Name: Reject-Contact
ヘッダーフィールド名：拒否コンタクト
Compact Form: j
コンパクトフォーム：j
The following is the registration for the Request-Disposition header field:
以下は、リクエスト閉鎖ヘッダーフィールドの登録です。
RFC Number: RFC 3841
RFC番号：RFC 3841
Header Field Name: Request-Disposition
ヘッダーフィールド名：リクエスト拡散
Compact Form: d
コンパクトフォーム：d
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.
この仕様で使用されるメディア機能タグの初期セットは、Scott PetrackのCMAデザインの影響を受けました。ジョナサン・レノックス、ボブ・ペンフィールド、ベン・キャンベル、メアリー・バーンズ、ロハン・マヒー、ジョン・ハーティは有益なコメントを提供しました。Graham Klyneは、RFC 2533の使用に関する支援を提供しました。
[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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、 "SIP：SESSION INTIATION Protocol"、RFC 3261、2002年6月。
[2] Klyne, G., "A Syntax for Describing Media Feature Sets", RFC 2533, March 1999.
[2] Klyne、G。、「メディア機能セットを説明するための構文」、RFC 2533、1999年3月。
[3] Rosenberg, J., Schulzrinne, J., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004.
[3] Rosenberg、J.、Schulzrinne、J。、およびP. Kyzivat、「セッション開始プロトコル（SIP）のユーザーエージェント機能を示す」、RFC 3840、2004年8月。
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[4] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[5] Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[5] Roach、A.B。、「セッション開始プロトコル（SIP）特異的イベント通知」、RFC 3265、2002年6月。
[6] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.
[6] Donovan、S。、「The SIP Info Method」、RFC 2976、2000年10月。
[7] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002.
[7] Rosenberg、J。およびH. Schulzrinne、「セッション開始プロトコル（SIP）における暫定的な応答の信頼性」、RFC 3262、2002年6月。
[8] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002.
[8] Rosenberg、J。、「セッション開始プロトコル（SIP）更新方法」、RFC 3311、2002年10月。
[9] Campbell, B., Ed., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002.
[9] Campbell、B.、Ed。、Rosenberg、J.、Schulzrinne、H.、Huitema、C。、およびD. Gurle、「インスタントメッセージング用のセッション開始プロトコル（SIP）拡張」、RFC 3428、2002年12月。
[10] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[10] Sparks、R。、「セッション開始プロトコル（SIP）参照メソッド」、RFC 3515、2003年4月。
[11] Lennox, J. and H. Schulzrinne, "Call Processing Language Framework and Requirements", RFC 2824, May 2000.
[11] Lennox、J。およびH. Schulzrinne、「コール処理言語のフレームワークと要件」、RFC 2824、2000年5月。
[12] Rosenberg, J., "Guidelines for Authors of Extensions to the Session Initiation Protocol (SIP)", Work in Progress, November 2002.
[12] Rosenberg、J。、「セッション開始プロトコル（SIP）への拡張著者の著者のガイドライン」、2002年11月、Work in Progress。
[13] Holtman, K., Muntz, A., and T. Hardie, "Media Feature Tag Registration Procedure", BCP 31, RFC 2506, March 1999.
[13] Holtman、K.、Muntz、A。、およびT. Hardie、「メディア機能タグ登録手順」、BCP 31、RFC 2506、1999年3月。
Jonathan Rosenberg dynamicsoft 600 Lanidex Plaza Parsippany, NJ 07054 US
Jonathan Rosenberg Dynamicsoft 600 Lanidex Plaza Parsippany、NJ 07054 US
Phone: +1 973 952-5000
EMail: jdrosen@dynamicsoft.com
URI: http://www.jdrosen.net
Henning Schulzrinne Columbia University M/S 0401 1214 Amsterdam Ave. New York, NY 10027 US
ヘニングシュルツリンコロンビア大学M/S 0401 1214 AMSTERDAM AVE. NEW YORK、NY 10027 US
EMail: schulzrinne@cs.columbia.edu
URI: http://www.cs.columbia.edu/~hgs
Paul Kyzivat Cisco Systems 1414 Massachusetts Avenue BXB500 C2-2 Boxboro, MA 01719 US
Paul Kyzivat Cisco Systems 1414 Massachusetts Avenue BXB500 C2-2 BOXBORO、MA 01719 US
EMail: pkyzivat@cisco.com
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）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。