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)
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）インターネット協会（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プロキシへのURIまたはにリダイレクトました
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.
ただし、サーバーの管理者は、要求の処理に興味を持つ唯一の存在ではありません。サーバーの（1）管理者、リクエストを送信した（2）利用者、および要求が向けられている人に（3）ユーザー：興味を持って、少なくとも3つの政党があります。管理者のディレクティブは、サーバのポリシーに埋め込まれています。要求（リクエストメソッドがINVITEではないかもしれないにもかかわらず、被呼者と称する）指向されたユーザの好みは、呼処理言語として、スクリプト言語のいくつかのタイプで書かれたスクリプトを介して最も容易に表すことができます。 （CPL）[11]。しかし、機構は（また、リクエストメソッドがINVITEでない場合でも、発信者と呼ばれる）要求を送信したユーザの嗜好を組み込むことがありません。たとえば、呼び出し側は、特定のユーザーに話したいかもしれませんが、コールはビジネスコールであるため、唯一の仕事でそれらに到達したいと考えています。別の例として、呼び出し側は、発信者が被呼者に話をすることが重要であることから、彼らのボイスメールユーザに到達したいのですが、ない場合があります。これらの例の両方で、プロキシを有することに、発信者の嗜好量は、発信者の好みに基づいて特定のルーティング選択をします。
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種類があります。リクエスト処理プリファレンスと呼ばれるそのうちの一つは、リクエスト-Dispositionヘッダーフィールドにカプセル化されています。彼らは、サーバー用のディレクティブを扱う特定の要求を提供します。その他、という機能の設定、受け入れ-連絡先に存在し、拒否-Contactヘッダーフィールド。彼らは、発信者が機能セットを提供することを可能にする[2]に到達するUAの特性に対するその選好を発現します。これらは、そのレジストラに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ナンバー」サービスです。ように自分の携帯電話、PDA、職場の電話、自宅の電話を、そして - ユーザーが自分のデバイスのすべてのための単一のID（自分のSIP URI）を持つことができます。呼び出し側が自社のビジネスフォンのユーザーに到達したい場合は、そのURIを呼び出すとき、彼らは単にオプションのプルダウンメニューから、「ビジネス電話」を選択します。ユーザーは、もはや維持し、各デバイスごとに個別のIDを配布する必要がないだろう。
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.
この文書では、キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "NOT SHALL"、 "推奨"、 "すべきではない" "べきである" "ないものと"、 "MAY"、および "オプション" 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 INVITEリクエストを送信し、ユーザーに限定されるものではありません。
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の所望の特性を記述する発信者の好み。機能の設定は、連絡先を受け入れ、拒否-Contactヘッダーフィールドで明示的に行うことができます。
Request Handling Preferences: Caller preferences that describe desired request treatment at a server. These preferences are carried in the Request-Disposition header field.
要求処理設定：サーバーでの所望の要求処理を記述する発信者の好み。これらのプリファレンスは、リクエスト-Dispositionヘッダーフィールドで運ばれます。
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.
暗黙的嗜好：リクエストの他の態様の存在を介して暗示される発信者嗜好。リクエストメソッドがINVITEである場合、例えば、それは、経路に暗黙発信者嗜好INVITEメソッドをサポートする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つのカテゴリに分類されます。要求処理優先と呼ばれる第一のカテゴリーは、要求-dispositionヘッダフィールド内で運ばれます。これは、サーバーで要求される特定の動作を説明します。要求処理優先発信者がプロキシにサーバーを望むか、リダイレクト、および連続的または並列検索が所望されるかどうかかどうかを含みます。これらの設定は、すべてのプロキシで適用されるか、コールシグナリングパス上のサーバにリダイレクトすることができます。
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.
機能の好みと呼ば好みの第二のカテゴリーは、受け入れ-連絡先と拒否-連絡先をヘッダフィールドで運ばれます。これらのヘッダーフィールドは、機能[3]を示すために使用される同一の特徴パラメータによって表される機能セットを含みます。ここで、特徴パラメータは、発信者の嗜好を表します。 Accept-Contactヘッダーフィールドは、発信者が到達したいのUAを記述する機能セットが含まれています。 Reject-Contactヘッダーフィールドは、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.
プロキシは受け入れ、連絡先の情報を使用し、そのターゲットセット内の接点の間で選択するために、ヘッダフィールド接触拒否します。これらのヘッダフィールドのどちらが存在する場合、プロキシは、要求からの暗黙的なプリファレンスを計算します。これらは明示的要求に置かれていない発信者の好みであるが、他のメッセージコンポーネントの存在から推測することができます。リクエストメソッドがINVITEである場合、一例として、これは、ルートへの暗黙の優先INVITEメソッドをサポートする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.
要求処理と機能の好みはどちらも、INVITEだけでなく、すべての要求に表示されます。しかし、彼らはプロキシが要求の対象を決定する必要があるリクエストでのみ有用です。リクエストURIにドメインが要求パスに沿った任意のプロキシによって所有されていない場合は、これらのプロキシは、ロケーション・サービスにアクセスすることはありません、そのため、呼び出し側の環境設定を適用する機会を持つことはありません。一般的に、リクエストURIは、ダイアログ中のリクエストのために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.
要求のための好みを表現することを望む発信者は、拒絶の接触、またはそれらの特定の好みに応じて、要求内のRequest-Dispositionヘッダーフィールド、-接触を受け入れ含みます。リクエストが送信された後、追加の行動は必要ありません。
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で、リクエスト-Dispositionヘッダーフィールド・コンタクトを拒否、またはCANCEL要求に、肯定応答またはキャンセルされ、元の要求の値に等しくなければなりません。これはステートレスプロキシ経由適正な動作を確保することです。
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は、経路に沿ったサーバは、本明細書に記載のヘッダフィールドを理解するかどうかを決定したい場合は、[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.
リクエスト-Dispositionヘッダーフィールドは、サーバーが要求を処理する方法のために、発信者の好みを指定します。その値は、特定の処理命令を指定各々がトークンのリストです。
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リクエストを送信した結果として到達していないされなければならないUAの能力の発信者の好みを示すことができます。これを行うには、それが一つ以上の-連絡先を受け入れ、拒否、連絡先ヘッダーフィールド値を追加します。各ヘッダフィールド値は特徴のセットを定義する特徴パラメータのセットを含みます。ヘッダフィールドの構文は、セクション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であっても、それが中に符号化されることを「sip.methods」機能タグ（ただし、で設定したAccept-接触機能で用語を含めることをお勧めしますその値は、要求の方法を含む受け入れる-Contactヘッダフィールドとして単に「方法」）。 UAは、SUBSCRIBEリクエストを送信すると、UA、その値は、要求のイベントパッケージを含む「sip.events」機能タグ、で設定したAccept-連絡先機能での用語を含めることをお勧めします。これらの用語は、新たな機能セットに配置されているかどうか、またはそれらは、各機能セットに含まれているかどうか、実装者の裁量です。ほとんどの場合、右の効果は、各機能セット中の用語を含むことによって達成されます。
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"
受け入れ-接触：*;モビリティ= "モバイル";メソッドは、= "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.
Reject-Contactヘッダーフィールドは、ヘッダフィールドの値のいずれかに一致した場合、UAは連絡をしてはならないことを指定するには、UACを可能にします。 Reject-Contactヘッダーフィールドの各値は、純粋にSIP拡張子[12]のためのガイドラインに構文を整列させるために、「*」が含まれ、特徴パラメータのセットによってパラメータ化されます。その機能の特徴パラメータによって記述される機能セットに一致するUAは、値が一致します。
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ヘッダーフィールドは、ヘッダフィールドの値の一部またはすべてに一致した場合、UAに連絡する必要があることを指定するには、UACを可能にします。 Accept-Contactヘッダーフィールドの各値は「*」が含まれており、特徴パラメータのセットによってパラメータ化されます。その機能の特徴パラメータによって記述される機能セットに一致するUAは、値が一致します。正確な動作は、「必要」と「明示的な」パラメータが存在しているかどうかに大きく依存します。それらの両方が存在する場合、プロキシは、明示的にのみ、それらが所望の機能セットをサポートすることが示されている連絡先に要求を転送します。他のものは破棄されます。それは接触が決定的に一致しない限り失敗するコールを希望する際にそのように、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に要求。ここで、「最高の」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.
唯一の「明示的」存在する場合、それは、呼び出し先が提供するすべての連絡先が使用されることを意味します。連絡先が明示的に一致していない場合しかし、それは同じ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.
存在する場合、どちらも「明示的」を「必要」でも最後に、それは呼び出し先が提供するすべての連絡先が使用されることを意味します。接触が一致しない場合しかし、それは同じ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の登録連絡先のいずれかに対応する要求を受信すると、それは要求URI内のドメインのプロキシであるかのように、それはセクション7.2に記載された動作を適用すべきです。その位置データベースはリクエストURIのための単一の要求のターゲットが含まれている場合のようにUASが作用します。そのターゲットは、機能セットに関連付けられています。機能セットは、リクエスト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が存在する場合、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は、リクエストで要求-Dispositionヘッダーフィールド内の任意のキューディレクティブ本を処理しなければなりません。他のすべてのディレクティブを無視しなければなりません。
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.
受け入れ接触してのRequest-Dispositionヘッダーフィールドを処理するための1つ、およびURIを処理するための1つの特徴セット好みや拒否-Contactヘッダフィールド - プロキシ動作は、2つの直交ルールの組から成ります。
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.
存在しない場合は、これらのヘッダを処理することに加えて、プロキシは、一つの追加もよく、またはそれはUACであるかのように、既存のヘッダーフィールドに値を追加します。これは、機能の実装の下流プロキシの処理を要求するプロキシのために有用です。しかし、プロキシは既存のヘッダーフィールドの値を変更したり、削除してはいけません。 S / MIMEを使用する場合、これは特に重要です。メッセージ署名は、発信者の好みは、元の発信者の好みがまだ存在していたプロキシがヘッダーフィールドを追加した場合でも、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.
要求がRequest-Dispositionヘッダーフィールドを含み、それはリクエスト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.
それは、要求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.
プロキシ処理の最初のステップは、明示的な嗜好を抽出することです。これを行うには、それは、連絡先を受け入れ、拒否-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』、 『俳優』、または 『テキスト』、または名前がプラス（+）で始まります[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つの優先ヘッダフィールドの1つに関連付けられるそれぞれが連言標準形で機能セット述部の集合であろう。 Accept-Contactヘッダーフィールド内のヘッダフィールド値に関連付けられているREQパラメータがあった場合、そのヘッダーフィールド値から導出機能セット述語は、その必要とするフラグが設定されていると言われています。 Accept-Contactヘッダーフィールド内のヘッダフィールド値に関連付けられた明示PARAMがあった場合も同様に、そのヘッダーフィールド値から導出機能セット述語は、その明示的なフラグが設定されていると言われています。
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.
、および場合のみ場合（無接点を受け入れるか拒否-Contactヘッダーフィールドがなかったので）、プロキシはリクエストに明示的な好みを見つけることができませんでした、プロキシは、暗黙的な嗜好を抽出します。これらの設定は、要求内の他の情報の存在によって暗黙ものです。
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:
一つの暗黙的な好みは方法です。 UACは、特定の方法で要求を送信すると、それだけでそのメソッドをサポートするUAにルーティングされた要求を持っている暗黙の好みです。この暗黙のプリファレンスをサポートするために、プロキシは、次の形式の組み合わせに用語を追加します。
(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] Contactヘッダフィールドから特徴パラメータを抽出してコンタクト述語を計算します。特徴パラメータを抽出するには、プロキシは、次の手順を実行します。
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.いずれかの連絡先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値に関連付けられます。接触述語がREGISTERリクエストを通じて学習された場合は、q値は、ContactヘッダーフィールドパラメータでQ値に等しい、それ以外の指定がない場合は「1.0」。
As an example, consider the following registered Contact header field:
例として、以下の登録Contactヘッダーフィールドを考えてみます。
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)))
（＆（sip.audio = TRUE）（sip.video = TRUE）（sip.mobility =固定）（sip.message = TRUE）（|（sip.methods =（sip.methodsの=オプション）INVITE）（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 +.
それはどちらもベースタグであるため、「他の-paramは」、特徴パラメータを考慮していないにもそれが有力+で始まるなかったことに注意してください。
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 =「<値>」）、それは、大文字と小文字が区別文字列比較を暗示します。それらが存在しない場合、（すなわち、（+ sip.bar =「ヴァル」）、それはケース非感受性を意味ニューメリックは、通常の数学的比較を使用して一致しています。
First, the proxy applies the predicates associated with the Reject-Contact header field.
まず、プロキシは、Reject-Contactヘッダーフィールドに関連付けられた述語を適用します。
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.
各コンタクト述語のために、各拒否接触述語は（すなわち、Reject-Contactヘッダーフィールドに関連付けられた各述語で）検査されます。その拒否接触述語は、フィーチャータグのフィルタが含まれており、その機能のタグはどこにでも接触述語に存在しない場合は、その拒否接触述語は、その接触述語の処理のために破棄されます。拒否接触述語が破棄されていない場合は、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.
次に、プロキシは受け入れ-連絡先をヘッダフィールドに関連付けられた述語を適用します。ターゲットセットに残っている各連絡先について、プロキシはマッチングセットを構築し、氏は当初、このセットは受け入れ-連絡先を述語がすべて含まれています。これらの述語のそれぞれを調べています。これは、RFC 2533のマッチング操作を使用して接触述語と一致している[2]。結果が一致していない、とのAccept-連絡先の述語が必要とフラグセットを持っていた場合、その連絡先の述語に対応するURIを設定し、ターゲットから破棄されます。結果が一致ではなく、受け入れ接触述語が必要とフラグセットを持っていなかった場合は、その連絡先URIをターゲットセットから破棄されていない、しかし、受け入れ-コンタクト述語は、その連絡先に設定されたマッチングから削除されます。
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-問い合わせ述語一緒に用語の数がNに等しいとします。接触述語が同じ機能タグを含む用語がある場合、スコアは1 / Nだけインクリメントされます。フィーチャータグが接触述語に存在していなかった場合、スコアは変わりません。これらのルールに基づいて、スコアは0と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未満だった場合、このプロセスは、図1に要約され、受け入れ-コンタクト述語は、明示的なタグを持っていた、と述語も必要とタグを持っていた場合は、連絡先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.
次のステップは、全体的な発信者の好み、のQaに到達するために、マッチングセット内の述語に関連付けられたスコアとQ値を組み合わせることです。残るターゲットセットにおけるそれらのURIについて、マッチング・セット内の各受け入れ、連絡先を述語に対してその一致を示すスコアがあるでしょう。 MのAccept-問い合わせはマッチングセットに述語がある場合は、各連絡先のSMによるMスコアS1、あるでしょう。全体的な発信者の好み、Qaが、SMを介してS1の算術平均です。
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.
発信者の嗜好のQaの目的は、被呼者が順序を提供していない場合、ターゲットセットに残っている連絡先の順序を提供することです。これを行うには、ターゲットセットに残っている連絡先は、呼び出し先が提供する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の世代になります。この動作は、明示的な設定の場合に許容可能な、そして実際に、望ましいです。呼び出し側が明示的な好みをするとき、その要求があるため好みの不一致失敗するかもしれないことを合意しています。一つは、発信者は、おそらく再び試みることができるように、呼び出し先の能力を示すエラーを返すように試みる場合があります。しかし、そうすることは着呼側からの許可なしに、発信者に対して潜在的な機密情報の漏洩につながるので、この仕様はそのための手段を提供していません。
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.
プロキシサーバが再帰されている場合は、Contactヘッダーフィールドは、ターゲットセットにリダイレクト応答で返され、呼び出し側の好みのアルゴリズムを再適用する追加します。
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値を割り当てます。しかし、それはターゲットセット内のエントリの特徴パラメータを含んではいけません。それがなかった場合は、上位プロキシサーバーは、これらの好みの二重のアプリケーションで、その結果、もう一度同じ、発信者の好みを適用します。リダイレクトサーバーは、Contactヘッダーフィールドにおける特徴パラメータを含めたいならば、それは、発信者の好みの適用前に、元のターゲットセットとオリジナルの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に送信INVITE：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
*;オーディオ;のAccept-連絡先が必要です：：ビデオのAccept-接触;俳優= "MSG-係を"; *：・連絡先を拒否;ビデオ; *明示的にAccept-接触：*;メソッド= "BYE";クラス= "ビジネス" ; 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つの接点の各々は、三受け入れ接触述語のそれぞれと比較されます。 U1は、最初の2つの述語のために1.0のスコアを獲得3つのすべてに一致し、及び第三0.5（方法タグは、コンタクト述部に存在していますが、クラスのタグがなかった）です。 U2は、最初の述部と一致していません。その述語が必要とタグを持っているため、U2は破棄されます。 U4は1.0のスコアを獲得し、最初の述語に一致します。 U4は、第二の述語と一致するが、一致が（スコアは、実際には、0.0である）、明示的ではないので、スコアは（それが既にゼロであったので、何も変化）がゼロに設定されています。 U4は、第三の述語と一致していません。
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が残ります。そのマッチングセットは3つすべてを含んでいるので、U1は、1,1、および0.5のスコアと、すべての3つのAccept-コンタクト述部に一致しました。 U4は、1.0と0.0のスコアと、最初の2つの述部に一致します。 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は、U1が0.2のq値を有しているので、U4を行い、0.5の値を有します。 2つの同値クラスがあります。最初は0.5のq値を有し、ちょうどU5から成ります。このクラスの唯一のメンバーが存在するので、クラス内でソートしても影響を与えません。第二等価クラスは0.2のq値を有しています。そのクラスの中で、二つの接点、U1およびU4は、Qaとのそれらの値に基づいて順序付けされています。 U1は、0.83のQaの、及びU4、0.5のQaとを有しています。このように、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".
機能-PARAMのセットから開始し、手順は以下のとおりです。接続詞を構築します。一緒にそれぞれの用語は、一つの特徴-のparamに由来します。機能-paramは値を持たない場合、それは「TRUE」の値を持っていたかのように、次の処理の面で、同等です。
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.
機能-のparam値がタグ値リストである場合は、接続詞の要素が論理和です。タグ値リスト内の各タグ値の和に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.
ここで、「<残りからフィルタ>」は、感嘆符が存在していなかった場合、タグ値から構成されるフィルタを意味します。
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:
タグ値は、シャープ（＃）で始まっている場合、フィルタは数値の比較です。コンパレータのいずれか=、> =、<=、またはフレーズの次の文字に基づいた範囲です。次の文字が=、> =、またはある場合<=、フィルタの形式です。
(name 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.コンペア値は、 "に設定されていますI / 10 ** 10 ** Nは、N番目のパワーに数10を計算した結果であるN」、。
If the value after the octothorpe is a number, the filter is a range. The format of the filter is:
シャープ後の値が数値である場合、フィルタは範囲です。フィルタの形式は次のとおりです。
(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 (..).
それはデコードされた後に「名前」は、機能タグである場合、合理的な形式に変換任意の10進数で（下記参照）、および「<残りは>」、＃の後にタグ値内のテキストの残りの部分であり、コロンは、二重ドット（..）に置き換えられました。
If the tag-value does not begin with an octothorpe (it is a token-nobang or boolean), the filter is of the form:
タグ値は、（それがトークンnobangまたはブール値である）シャープで始まらない場合、フィルタの形式は次のとおりです。
(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:
機能-paramは文字列値が含まれている場合（それは左の山かっこで始まるという事実に基づいて（「<」）と右かぎカッコ（「>」））、フィルタの形式は次のとおりです。
(name="qdtext")
（名前= "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]は、直接のAccept-問い合わせ、問い合わせのヘッダフィールドパラメータとして表現することができず、拒否コンタクトヘッダフィールド。これは文法であり、他の拡張機能で使用されるパラメータから特徴パラメータを区別する必要性に矛盾によるものです。このように、特徴タグ値は、ENC-機能タグを生成するためにRFC 2506形式から符号化され、その後RFC 2506形式に復号されます。復号化プロセスは簡単です。先頭にプラス（+）記号がある場合、それが削除されます。任意の感嘆符（！）、コロン（:)と任意の単一引用符（ '）、スラッシュ（/に変換される）に変換されます。何の先頭にプラス記号、符号化された名前の残りの部分は見られなかった場合だった「オーディオ」、「オートマトン」、「クラス」、「両面」、「データ」、「制御」、「モビリティ」、「説明」、「イベント」、 『優先順位』、 『方法』、 『スキーム』、 『アプリケーション』、 『ビデオ』、 『俳優』、 『isfocus』、 『拡張』または 『テキスト』、接頭辞 『一口。』特徴タグ名を計算するために符号化された名前の残りの部分に付加されます。
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"
受け入れ-接触：*;移動度は= "固定";イベント= "プレゼンス、メッセージサマリ！";言語は= "EN、デ";説明= "<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は、表2の拡張及び3 RFC 3261 [1]のAccept-接触するため、拒否接触して、リクエスト-Dispositionヘッダーフィールドです。カラム "INF" はINFO方式のためのものである[6]、 "PRA" はPRACK方法のためのものである[7]、 "UPD" は、UPDATEメソッドのためのものである[8]、 "SUB" は、SUBSCRIBEメソッドのためのものである[5] [9] [5]、 "MSG" はMESSAGEメソッドのためのものであるNOTIFYメソッドのためであり、そして "REF" は、REFERメソッドのためのものである[10] "NOT"。
Header field where proxy ACK BYE CAN INV OPT REG
ヘッダフィールドプロキシACK BYE CAN INV OPT REG
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
Accept-問い合わせ空気O O R O - R拒否-問い合わせ空気〇〇〇〇〇 - 要求 - ディスポジション空気A〇〇〇〇〇〇
Figure 2: Accept-Contact, Reject-Contact, and Request-Disposition header fields
図2のAccept-接触、拒絶問い合わせ、リクエスト-Dispositionヘッダーフィールド
Header field where proxy PRA UPD SUB NOT INF MSG REF
プロキシPRA UPDのSUBはMSG REFをINFませヘッダフィールド
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
エアR〇〇〇〇〇〇〇R拒否-問い合わせ空気〇〇〇〇〇〇〇要求 - ディスポジションの空気A〇〇〇〇〇〇〇 - 連絡先受け入れます
Figure 3: Accept-Contact, Reject-Contact, and Request-Disposition header fields
図3のAccept-接触、拒絶問い合わせ、リクエスト-Dispositionヘッダーフィールド
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).
リクエスト-Dispositionヘッダーフィールドは、サーバーが要求を処理する方法のために、発信者の好みを指定します。その値は、特定のディレクティブを指定するそれぞれのトークンのリスト、です。その構文は、文字dを使用して、コンパクトなフォームは、定義されている第10注記に指定されています。ディレクティブは、タイプに分類されています。唯一の要求（例えば、あなたが「プロキシ」の両方を持つことができず、同じ要求-dispositionヘッダフィールドに「リダイレクト」）あたりの各タイプの命令が存在することができます。
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要求（「キャンセル」）を送信するために各プロキシサーバーを希望するかどうかを示す通常の動作モードである下流サーバ（からOK 200に応答し、それを冗長化）、またはこの関数は呼び出し側に残されるべきかどうか（「ノーキャンセル」）。プロキシが「ノーキャンセル」に設定されていない、このパラメータを指定して要求を受信した場合、それは2XXの受信時に未処理の枝をキャンセルすべきではありません。しかし、それはまだの6xxの受信時に未処理の枝にCANCELを送信します。
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しないように要求された場合、サーバーは、プロキシ「最良」のアドレス（最高q値を持つ一般1）に要求をする必要があります。最高の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応答を受信したプロキシサーバが応答（「再帰」）に記載されているアドレスにリクエストを送信し、または発信者（「非再帰」）に向けて上流のアドレスのリストを転送するかどうかを示します。 「リダイレクト」は、要求された場合ディレクティブは無視されます。
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].
キュー・ディレクティブ：被呼者は、それが別のコールであるため、呼び出し側は、その呼び出しが（「キュー」）をキューに入れられたか（「無キュー」）、すぐに拒否されていない持って望んでいることを示すことができ、例えば、一時的に到達できない場合。コールがキューイングされている場合は、サーバが「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.
これらのヘッダフィールドの構文は、のAccept-Contactヘッダーフィールドに定義されている文字で、第10コンパクトな形で説明し、およびReject-Contactヘッダーフィールドのための文字jを有するされます。
The BNF for the Request-Disposition header field is:
リクエスト-Dispositionヘッダーフィールドの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"
要求処分=（「リクエストの廃棄」/「D」）HCOLON指令*（COMMAディレクティブ）ディレクティブは、=プロキシ指示/キャンセルディレクティブ/フォーク指令/再帰ディレクティブ/パラレル指令/キュー指令プロキシディレクティブ=「プロキシ」/「リダイレクトする」キャンセルディレクティブ=「キャンセル」/「NOキャンセル」フォーク指令=「フォーク」/「NOフォーク」再帰ディレクティブ=「再帰」/「非再帰ない」並列ディレクティブ=「パラレル」/「シーケンシャル」キュー・ディレクティブ=「キュー」/「無キューません」
The BNF for the Accept-Contact and Reject-Contact header fields is:
受け入れ-連絡先と拒否 - コンタクトヘッダフィールドの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"
Accept-連絡先=（ "にAccept-連絡先を" / "A"）HCOLON交流-値*（COMMA交流-値）=（ "拒否 - 連絡先を" / "J"）、連絡先を拒否HCOLONのRC-値*（COMMA RC-値）AC-値= "*" *（SEMI AC-のparams）RC-値= "*" *（SEMI RC-のparams）AC-のparams =機能-PARAM / REQ-PARAM /明示的な-PARAM /ジェネリック-PARAM。 ; RFC 3261、RC-のparams =機能-PARAM /ジェネリック-のparam REQ-PARAM = "必要" 明示的な-PARAM = "明示的な" からRFC 3840 ;;ジェネリック-PARAMから特徴のparam
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または明示的-PARAMがあってはなりません。さらに、唯一の特徴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の方法に従って、3つの新しいSIPヘッダフィールドを登録する[1]。
The following is the registration for the Accept-Contact header field:
以下は受け入れ-Contactヘッダーフィールドの登録です。
RFC Number: RFC 3841
RFC番号：RFC 3841
Header Field Name: Accept-Contact
ヘッダーフィールド名：受け入れ-問い合わせ
Compact Form: a
コンパクトなフォーム：
The following is the registration for the Reject-Contact header field:
以下は、Reject-Contactヘッダーフィールドの登録です。
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:
以下は、Request-Dispositionヘッダーフィールドの登録です。
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.
この仕様で使用されるメディアフィーチャータグの初期セットは、スコット2000 PetrackとのCMAのデザインに影響を受けました。ジョナサン・レノックス、ボブペンフィールド、ベン・キャンベル、メアリー・バーンズ、ローハンマーイ、およびジョン・ハーティは役に立つコメントを提供しました。グラハム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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、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]ローゼンバーグ、J.、Schulzrinneと、J.、およびP. Kyzivatを、RFC 3840、2004年8月 "セッション開始プロトコル（SIP）におけるユーザエージェントの能力を示します"。
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[4]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[5] Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[5]ローチ、A.B.、 "セッション開始プロトコル（SIP）特異的イベント通知"、RFC 3265、2002年6月。
[6] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.
[6]ドノバン、S.、 "SIP INFOメソッド"、RFC 2976、2000年10月。
[7] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002.
[7]ローゼンバーグ、J.、およびH. Schulzrinneと、RFC 3262、2002年6月 "セッション開始プロトコル（SIP）における暫定的な応答の信頼性"。
[8] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002.
[8]ローゼンバーグ、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]キャンベル、B.、編。、ローゼンバーグ、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]スパークス、R.、 "セッション開始プロトコル（SIP）メソッドを参照してください"、RFC 3515、2003年4月。
[11] Lennox, J. and H. Schulzrinne, "Call Processing Language Framework and Requirements", RFC 2824, May 2000.
[11]レノックス、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.
、進歩、2002年11月に作業[12]ローゼンバーグ、J.、「セッション開始プロトコル（SIP）への拡張の著者のためのガイドライン」。
[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.ハーディ、 "メディア特徴タグの登録手順"、BCP 31、RFC 2506、1999年3月。
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
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機能のための基金は現在、インターネット協会によって提供されます。