Network Working Group H. Schulzrinne
Request for Comments: 4412 Columbia U.
Category: Standards Track J. Polk
Cisco Systems
February 2006
Communications Resource Priority 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 (2006).
著作権（C）インターネット協会（2006）。
Abstract
抽象
This document defines two new Session Initiation Protocol (SIP) header fields for communicating resource priority, namely, "Resource-Priority" and "Accept-Resource-Priority". The "Resource-Priority" header field can influence the behavior of SIP user agents (such as telephone gateways and IP telephones) and SIP proxies. It does not directly influence the forwarding behavior of IP routers.
この文書は、リソース優先順位、即ち、「リソース優先」および「受け入れ資源優先」を通信するために二つの新しいセッション開始プロトコル（SIP）ヘッダフィールドを定義します。 「リソース優先」のヘッダフィールドは、（例えば、電話ゲートウェイやIP電話などの）SIPユーザエージェントとSIPプロキシの挙動に影響を与えることができます。これは、直接IPルータの転送動作に影響を与えません。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................6
3. The Resource-Priority and Accept-Resource-Priority SIP
Header Fields ...................................................6
3.1. The 'Resource-Priority' Header Field .......................6
3.2. The 'Accept-Resource-Priority' Header Field ................8
3.3. Usage of the 'Resource-Priority' and
'Accept-Resource-Priority' .................................8
3.4. The 'resource-priority' Option Tag .........................9
4. Behavior of SIP Elements That Receive Prioritized Requests ......9
4.1. Introduction ...............................................9
4.2. General Rules ..............................................9
4.3. Usage of Require Header with Resource-Priority ............10
4.4. OPTIONS Request with Resource-Priority ....................10
4.5. Approaches for Preferential Treatment of Requests .........11
4.5.1. Preemption .........................................11
4.5.2. Priority Queueing ..................................12
4.6. Error Conditions ..........................................12
4.6.1. Introduction .......................................12
4.6.2. No Known Namespace or Priority Value ...............13
4.6.3. Authentication Failure .............................13
4.6.4. Authorization Failure ..............................14
4.6.5. Insufficient Resources .............................14
4.6.6. Busy ...............................................14
4.7. Element-Specific Behaviors ................................15
4.7.1. User Agent Client Behavior .........................15
4.7.2. User Agent Server Behavior .........................15
4.7.3. Proxy Behavior .....................................16
5. Third-Party Authentication .....................................17
6. Backwards Compatibility ........................................17
7. Examples .......................................................17
7.1. Simple Call ...............................................18
7.2. Receiver Does Not Understand Namespace ....................19
8. Handling Multiple Concurrent Namespaces ........................21
8.1. General Rules .............................................21
8.2. Examples of Valid Orderings ...............................21
8.3. Examples of Invalid Orderings .............................22
9. Registering Namespaces .........................................23
10. Namespace Definitions .........................................24
10.1. Introduction .............................................24
10.2. The "DSN" Namespace ......................................24
10.3. The "DRSN" Namespace .....................................25
10.4. The "Q735" Namespace .....................................25
10.5. The "ETS" Namespace ......................................26
10.6. The "WPS" Namespace ......................................26
11. Security Considerations .......................................27
11.1. General Remarks ..........................................27
11.2. Authentication and Authorization .........................27
11.3. Confidentiality and Integrity ............................28
11.4. Anonymity ................................................29
11.5. Denial-of-Service Attacks ................................29
12. IANA Considerations ...........................................30
12.1. Introduction .............................................30
12.2. IANA Registration of 'Resource-Priority' and
'Accept-Resource-Priority' Header Fields .................30
12.3. IANA Registration for Option Tag resource-priority .......31
12.4. IANA Registration for Response Code 417 ..................31
12.5. IANA Resource-Priority Namespace Registration ............31
12.6. IANA Priority-Value Registrations ........................32
13. Acknowledgements ..............................................32
14. References ....................................................33
During emergencies, communications resources (including telephone circuits, IP bandwidth, and gateways between the circuit-switched and IP networks) may become congested. Congestion can occur due to heavy usage, loss of resources caused by the natural or man-made disaster, and attacks on the network during man-made emergencies. This congestion may make it difficult for persons charged with emergency assistance, recovery, or law enforcement to coordinate their efforts. As IP networks become part of converged or hybrid networks, along with public and private circuit-switched (telephone) networks, it becomes necessary to ensure that these networks can assist during such emergencies.
緊急時に、（電話回線、IP帯域幅、回線交換とIPネットワークの間のゲートウェイを含む）通信リソースが混雑してもよいです。輻輳が原因大量使用、天然または人災によって引き起こされる資源の損失、および人工緊急時のネットワークへの攻撃に発生する可能性があります。この混雑は彼らの努力を調整するために緊急援助、回復、または法執行機関で起訴者のための、それが困難になることがあります。 IPネットワークは、パブリックおよびプライベート回線交換（電話）ネットワークと共に、収束またはハイブリッドネットワークの一部になるように、これらのネットワークは、このような緊急時に支援することができることを確実にするために必要となります。
Also, users may want to interrupt their lower-priority communications activities and dedicate their end-system resources to the high-priority communications attempt if a high-priority communications request arrives at their end system.
また、ユーザーは自分の優先順位の低い通信活動を中断し、優先度の高い通信要求がそのエンドシステムに到着した場合、優先度の高い通信しようとしたことにそのエンド・システム資源を捧げたいことがあります。
There are many IP-based services that can assist during emergencies. This memo only covers real-time communications applications involving the Session Initiation Protocol (SIP) [RFC3261], including voice-over-IP, multimedia conferencing, instant messaging, and presence.
緊急時に支援することができ、多くのIPベースのサービスがあります。このメモはボイスオーバーIP、マルチメディア会議、インスタントメッセージング、プレゼンスなどのセッション開始プロトコル（SIP）[RFC3261]を伴うリアルタイム通信アプリケーションをカバーしています。
SIP applications may involve at least five different resources that may become scarce and congested during emergencies. These resources include gateway resources, circuit-switched network resources, IP network resources, receiving end-system resources, and SIP proxy resources. IP network resources are beyond the scope of SIP signaling and are therefore not considered here.
SIPアプリケーションは、緊急時希少で混雑になることがあり、少なくとも5つの異なるリソースを含むことができます。これらのリソースは、ゲートウェイリソース、回線交換ネットワークリソース、IPネットワークリソース、エンドシステムリソースを受信し、SIPプロキシリソースを含みます。 IPネットワークのリソースは、SIPシグナリングの範囲を超えているため、ここでは考慮されていません。
Even if the resources at the SIP element itself are not scarce, a SIP gateway may mark outgoing calls with an indication of priority, e.g., on an ISUP (ISDN User Part) IAM (Initial Address Message) originated by a SIP gateway with the Public Switched Telephone Network (PSTN).
SIP要素自体のリソースが不足していない場合でも、SIPゲートウェイは、ISUP公開とSIPゲートウェイによって発信（ISDNユーザ部）IAM（初期アドレスメッセージ）に、例えば、優先順位の表示と発信コールをマークします交換電話網（PSTN）。
In order to improve emergency response, it may become necessary to prioritize access to SIP-signaled resources during periods of emergency-induced resource scarcity. We call this "resource prioritization". The mechanism itself may well be in place at all times, but may only materially affect call handling during times of resource scarcity.
緊急対応を向上させるためには、緊急誘導性資源不足の期間中SIP-シグナリングリソースへのアクセスを優先するために必要になることができます。私たちは、この「リソースの優先順位付け」と呼びます。メカニズム自体はよく、すべての回での場所にあってもよいが、唯一の実質資源不足の時代に呼処理に影響を与える可能性があります。
Currently, SIP does not include a mechanism that allows a request originator to indicate to a SIP element that it wishes the request to invoke such resource prioritization. To address this need, this document adds a SIP protocol element that labels certain SIP requests.
現在、SIPは、要求元がそのようなリソースの優先順位付けを起動する要求を望むSIP要素に指示することを可能にする機構を備えていません。このニーズに対処するために、この文書は、特定のSIPリクエストをラベルSIPプロトコル要素を追加します。
This document defines (Section 3) two new SIP header fields for communications resource priority, called 'Resource-Priority' and 'Accept-Resource-Priority'. The 'Resource-Priority' header field MAY be used by SIP user agents, including Public Switched Telephone Network (PSTN) gateways and terminals, and SIP proxy servers to influence their treatment of SIP requests, including the priority afforded to PSTN calls. For PSTN gateways, the behavior translates into analogous schemes in the PSTN, for example, the ITU Recommendation Q.735.3 [Q.735.3] prioritization mechanism, in both the PSTN-to-IP and IP-to-PSTN directions. ITU Recommendation I.255.3 [I.255.3] is another example.
この文書定義（第3）「リソース優先」と「受け入れ資源優先」と呼ばれる通信リソースの優先順位のための2つの新しいSIPヘッダフィールド、。 「リソース優先」ヘッダフィールドは、公衆PSTN通話に与えられる優先順位を含め、SIPリクエストの彼らの治療に影響を与えるために電話網（PSTN）ゲートウェイおよび端末、SIPプロキシサーバを交換含め、SIPユーザエージェントによって使用されるかもしれません。 PSTNゲートウェイの場合、動作は、例えば、PSTNに類似の方式に変換し、ITU勧告Q.735.3 [Q.735.3]優先順位付け機構における双方PSTNとIPとIPとPSTN方向。 ITU勧告I.255.3 [I.255.3]別の例です。
A SIP request with a 'Resource-Priority' indication can be treated differently in these situations:
「リソース優先」表示とSIPリクエストはこのような状況では異なって処理することができます。
1. The request can be given elevated priority for access to PSTN gateway resources, such as trunk circuits.
1.リクエストは、中継回線としてPSTNゲートウェイリソースへのアクセスのための高められた優先度を与えることができます。
2. The request can interrupt lower-priority requests at a user terminal, such as an IP phone.
2.リクエストは、IP電話などのユーザ端末でより低い優先度の要求を、中断することができます。
3. The request can carry information from one multi-level priority domain in the telephone network (e.g., using the facilities of Q.735.3 [Q.735.3]) to another, without the SIP proxies themselves inspecting or modifying the header field.
前記要求はSIP自体がヘッダフィールドを検査または変更プロキシなしに、別の電話ネットワーク内の1つのマルチレベル優先ドメイン（例えば、Q.735.3の設備を使用して、[Q.735.3]）からの情報を運ぶことができます。
4. In SIP proxies and back-to-back user agents, requests of higher priorities may displace existing signaling requests or bypass PSTN gateway capacity limits in effect for lower priorities.
SIPプロキシ4.とバックツーバックユーザエージェントは、より高い優先順位の要求が低い優先順位のために有効な既存のシグナリング要求またはバイパスPSTNゲートウェイの容量の制限を移動してもよいです。
This header field is related to, but differs in semantics from, the 'Priority' header field ([RFC3261], Section 20.26). The 'Priority' header field describes the importance that the SIP request should have for the receiving human or its agent. For example, that header may be factored into decisions about call routing to mobile devices and assistants and about call acceptance when the call destination is busy. The 'Priority' header field does not affect the usage of PSTN gateway or proxy resources, for example. In addition, any User Agent Client (UAC) can assert any 'Priority' value, and usage of 'Resource-Priority' header field values is subject to authorization.
このヘッダフィールドはに関連するが、「優先度」ヘッダフィールド（[RFC3261]、セクション20.26）、からセマンティクスが異なるされます。 「優先順位」ヘッダフィールドは、SIP要求を受けた人またはその代理人のために持っている必要があることの重要性を説明しています。例えば、そのヘッダーは、モバイル機器とアシスタントにコールルーティングに関する決定に織り込まと着信先がビジーである場合について受諾を呼び出すことができます。 「優先度」のヘッダフィールドは、例えば、PSTNゲートウェイまたはプロキシ・リソースの使用量に影響を及ぼしません。加えて、任意のユーザエージェントクライアント（UAC）は、任意の「優先度」の値をアサートすることができ、「リソースプライオリティ」ヘッダフィールド値の使用は、許可を受けます。
While the 'Resource-Priority' header field does not directly influence the forwarding behavior of IP routers or the use of communications resources such as packet forwarding priority, procedures for using this header field to cause such influence may be defined in other documents.
「リソース優先」ヘッダフィールドは直接IPルータの転送動作や、パケット転送優先順位などの通信リソースの使用に影響を与えないが、このような影響を引き起こすために、このヘッダフィールドを使用するための手順は、他のドキュメントで定義されてもよいです。
Existing implementations of RFC 3261 that do not participate in the resource priority mechanism follow the normal rules of RFC 3261, Section 8.2.2: "If a UAS does not understand a header field in a request (that is, the header field is not defined in this specification or in any supported extension), the server MUST ignore that header field and continue processing the message". Thus, the use of this mechanism is wholly invisible to existing implementations unless the request includes the Require header field with the resource-priority option tag.
RFC 3261の通常の規則に従い、リソースの優先順位メカニズムに参加しないRFC 3261の実装、既存の、セクション8.2.2：UAS（つまりリクエストのヘッダフィールドを理解していない場合は」、ヘッダフィールドが定義されていません）本明細書において、またはサポートされている任意の拡張子に、サーバは、そのヘッダーフィールドを無視し、「メッセージの処理を継続しなければなりません。要求は、リソース優先順位オプションタグを要求ヘッダーフィールドが含まれていない限りこのように、この機構を使用することは、既存の実装に完全に見えません。
The mechanism described here can be used for emergency preparedness in emergency telecommunications systems, but is only a small part of an emergency preparedness network and is not restricted to such use.
ここで説明するメカニズムは、緊急通信システムにおける緊急時の準備のために使用されるが、防災ネットワークのほんの一部であり、そのような使用に限定されないことができます。
The mechanism aims to satisfy the requirements in [RFC3487]. It is structured so that it works in all SIP and Real-Time Transport Protocol (RTP) [RFC3550] transparent networks, defined in [RFC3487]. In such networks, all network elements and SIP proxies let valid SIP requests pass through unchanged. This is important since it is likely that this mechanism will often be deployed in networks where the edge networks are unaware of the resource priority mechanism and provide no special privileges to such requests. The request then reaches a PSTN gateway or set of SIP elements that are aware of the mechanism.
メカニズムは[RFC3487]で要件を満たすことを目指しています。それは、すべてのSIPおよびリアルタイムトランスポートプロトコル（RTP）[RFC3487]で定義された[RFC3550]透明ネットワークで動作するようにそれは構成されています。このようなネットワークでは、すべてのネットワーク要素とSIPプロキシが有効なSIPリクエストはそのまま通過してみましょう。このメカニズムは、多くの場合、エッジネットワークは、リソース優先順位メカニズムを知らないと、このような要求に特別な権限を与えていないネットワークで展開される可能性があるので、これは重要です。リクエストはその後PSTNゲートウェイに到達またはメカニズムを認識しているSIP要素のセット。
For conciseness, we refer to SIP proxies and user agents (UAs) that act on the 'Resource-Priority' header field as RP actors.
簡潔にするため、私たちはプロキシとRPの俳優として「リソース優先」ヘッダフィールドに作用するユーザエージェント（UAS）をSIPを参照してください。
It is likely to be common that the same SIP element will handle requests that bear the 'Resource-Priority' header fields and those that do not.
同じSIP要素が「リソース優先」ヘッダーフィールドとそうでないものを負担要求を処理することは一般的である可能性が高いです。
Government entities and standardization bodies have developed several different priority schemes for their networks. Users would like to be able to obtain authorized priority handling in several of these networks, without changing SIP clients. Also, a single call may traverse SIP elements that are run by different administrations and subject to different priority mechanisms. Since there is no global ordering among those priorities, we allow each request to contain more than one priority value drawn from these different priority lists, called a namespace in this document. Typically, each SIP element only supports one such namespace, but we discuss what happens if an element needs to support multiple namespaces in Section 8.
政府機関や標準化団体は、自社のネットワークのためのいくつかの異なる優先順位方式を開発しました。ユーザーがSIPクライアントを変更せずに、これらのネットワークのいくつかに認可優先扱いを得ることができるようにしたいと思います。また、単一のコールは、異なる優先順位メカニズムに異なる投与及び被験者によって実行されたSIP要素を横断することができます。これらの優先順位の中でグローバルな順序はありませんので、我々は、これらの異なる優先順位リストから引き出された複数の優先順位の値を含むように、各要求は、この文書の名前空間と呼ばれることができます。一般的に、各SIP要素は一つだけ、そのような名前空間をサポートしていますが、我々は要素がセクション8で複数の名前空間をサポートする必要がある場合に何が起こるかを話し合います。
Since gaining prioritized access to resources offers opportunities to deny service to others, it is expected that all such prioritized calls are subject to authentication and authorization, using standard SIP security (Section 11) or other appropriate mechanisms.
リソースへの優先順位のアクセスを獲得すると、他の人へのサービスを拒否する機会を提供していますので、標準のSIPセキュリティ（第11項）、または他の適切なメカニズムを使用して、このようなすべての優先順位のコールが認証および承認の対象となることが期待されます。
The remainder of this document is structured as follows. After defining terminology in Section 2, we define the syntax for the two new SIP header fields in Section 3 and then describe protocol behavior in Section 4. The two principal mechanisms for differentiated treatment of SIP requests (namely, preemption and queueing) are described in Section 4.5. Error conditions are covered in Section 4.6. Sections 4.7.1 through 4.7.3 detail the behavior of specific SIP elements. Third-party authentication is briefly summarized in Section 5. Section 6 describes how this feature affects existing systems that do not support it.
次のように、この文書の残りの部分は構成されています。第2に用語を定義した後、我々は、セクション3に二つの新しいSIPヘッダフィールドの構文を定義し、SIPリクエスト（つまり、プリエンプションおよびキューイング）の分化治療のための2つの主要な機構がに記載されている第4のプロトコルの動作を説明します4.5節。エラー条件は4.6節で説明されています。 4.7.3詳細特定のSIP要素の動作を介してセクション4.7.1。サードパーティの認証は簡単に5章6節に要約されているこの機能は、それをサポートしていない既存のシステムにどのような影響を与えるかについて説明します。
Since calls may traverse multiple administrative domains with different namespaces or multiple elements with the same namespace, it is strongly suggested that all such domains and elements apply the same algorithms for the same namespace, as otherwise the end-to-end experience of privileged users may be compromised.
呼び出しが同じ名前空間とは異なる名前空間または複数の要素を有する複数の管理ドメインを横断することができるので、そのようなすべてのドメインおよび要素が同じ名前空間に対して同じアルゴリズムを適用することが強く示唆され、特権ユーザのような、さもなければエンド・ツー・エンドの発生する可能性が危険にさらされます。
Protocol examples are given in Section 7. Section 8 discusses what happens if a request contains multiple namespaces or an element can handle more than one namespace. Section 9 enumerates the information that namespace registrations need to provide. Section 10 defines the properties of five namespaces that are registered through this document. Security issues are considered in Section 11, but this document does not define new security mechanisms. Section 12 discusses IANA considerations and registers parameters related to this document.
プロトコルの例は、第8節は、要求が複数の名前空間が含まれているかの要素が複数の名前空間を扱うことができるならば、何が起こるかを説明し、セクション7に与えられています。第9章は、名前空間の登録が提供する必要があるという情報を列挙します。第10節は、この文書を通じて登録されている5つの名前空間のプロパティを定義します。セキュリティ問題はセクション11で考慮されるが、この文書は、新しいセキュリティ・メカニズムを定義していません。セクション12は、IANAの考慮事項について説明し、このドキュメントに関連するパラメータを登録します。
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 [RFC2119], and indicate requirement levels for compliant implementations.
この文書では、キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "NOT SHALL"、 "推奨"、 "すべきではない" "べきである" "ないものと"、 "MAY"、および "オプション" BCP 14、RFC 2119 [RFC2119]に記載され、そして対応する実装の要求レベルを示すものとして解釈されるべきです。
This section defines the 'Resource-Priority' and 'Accept-Resource-Priority' SIP header field syntax. Behavior is described in Section 4.
このセクションでは、「資源の優先順位」と「受け入れ資源優先」SIPヘッダフィールドの構文を定義します。行動は、セクション4に記載されています。
The 'Resource-Priority' request header field marks a SIP request as desiring prioritized access to resources, as described in the introduction.
「リソース優先」リクエストヘッダフィールドは、導入部で説明したように、リソースへの優先アクセスを希望としてSIPリクエストをマーク。
There is no protocol requirement that all requests within a SIP dialog or session use the 'Resource-Priority' header field. Local administrative policy MAY mandate the inclusion of the 'Resource-Priority' header field in all requests. Implementations of this specification MUST allow inclusion to be either by explicit user request or automatic for all requests.
SIPダイアログまたはセッション内のすべての要求は、「資源の優先順位」ヘッダフィールドを使用して何のプロトコル要件はありません。ローカル管理ポリシーは、すべてのリクエストで「リソース優先」ヘッダフィールドを含めることを強制するかもしれません。この仕様の実装は含めることは、すべての要求のために、明示的なユーザ要求又は自動のいずれかであることを許容しなければなりません。
The syntax of the 'Resource-Priority' header field is described below. The "token-nodot" production is copied from [RFC3265].
「リソース優先」ヘッダフィールドの構文は以下の通りです。 「トークンnodot」生産は[RFC3265]からコピーされます。
Resource-Priority = "Resource-Priority" HCOLON r-value *(COMMA r-value) r-value = namespace "." r-priority namespace = token-nodot r-priority = token-nodot token-nodot = 1*( alphanum / "-" / "!" / "%" / "*" / "_" / "+" / "`" / "'" / "~" )
リソース優先=「リソース優先」HCOLONのr値*（COMMA r値）R値=名前空間「」 R-優先順位の名前空間=トークンnodotのR-優先=トークンnodotトークンnodot = 1 *（alphanum / " - " "！" / / "％" / "*" / "_" / "+" /「` "/ "'"/ "〜"）
An example 'Resource-Priority' header field is shown below:
例えば「リソースプライオリティ」ヘッダフィールドを以下に示します。
Resource-Priority: dsn.flash
資源優先度：dsn.flash
The 'r-value' parameter in the 'Resource-Priority' header field indicates the resource priority desired by the request originator. Each resource value (r-value) is formatted as 'namespace' '.' 'priority value'. The value is drawn from the namespace identified by the 'namespace' token. Namespaces and priorities are case-insensitive ASCII tokens that do not contain periods. Thus, "dsn.flash" and "DSN.Flash", for example, are equivalent. Each namespace has at least one priority value. Namespaces and priority values within each namespace MUST be registered with IANA (Section 12). Initial namespace registrations are described in Section 12.5.
「リソースプライオリティ」ヘッダフィールドに「R値」パラメータは、要求元が所望のリソースの優先度を示します。各リソース値（r値）が「「名前空間」としてフォーマットされています。」 「優先順位の価値」。値は、「名前空間」トークンによって識別された名前空間から引き出されます。名前空間と優先順位は、ピリオドを含まない、大文字と小文字を区別しないASCIIトークンです。このように、「dsn.flash」と「DSN.Flash」は、例えば、等価です。各名前空間は、少なくとも一つの優先度値を持ちます。各名前空間内の名前空間と優先順位値は、IANA（セクション12）に登録されなければなりません。初期名前空間の登録は、セクション12.5で説明されています。
Since a request may traverse multiple administrative domains with multiple different namespaces, it is necessary to be able to enumerate several different namespaces within the same message. However, a particular namespace MUST NOT appear more than once in the same SIP message. These may be expressed equivalently as either comma-separated lists within a single header field, as multiple header fields, or as some combination. The ordering of 'r-values' within the header field has no significance. Thus, for example, the following three header snippets are equivalent:
要求が複数の異なる名前空間を持つ複数の管理ドメインを横断することができるので、同じメッセージ内で複数の異なる名前空間を列挙できるようにする必要があります。しかし、特定の名前空間は同じSIPメッセージに複数回現れてはなりません。これらは、複数のヘッダフィールドとして、またはいくつかの組み合わせとして、単一のヘッダフィールド内のカンマ区切りのリストのいずれかと同等に表すことができます。ヘッダフィールド内の「R値」の順序は意味を持ちません。したがって、例えば、以下の三つのヘッダスニペットは等価です。
Resource-Priority: dsn.flash, wps.3
資源優先度：dsn.flash、wps.3
Resource-Priority: wps.3, dsn.flash
資源優先度：wps.3、dsn.flash
Resource-Priority: wps.3 Resource-Priority: dsn.flash
資源優先度：wps.3資源優先度：dsn.flash
The 'Accept-Resource-Priority' response header field enumerates the resource values (r-values) a SIP user agent server is willing to process. (This does not imply that a call with such values will find sufficient resources and succeed.) The syntax of the 'Accept-Resource-Priority' header field is as follows:
「受け入れ資源優先」レスポンスヘッダフィールドは、SIPユーザエージェントサーバが処理する意思があるリソース値（R値）を列挙する。 （これは、このような値を持つ呼び出しが十分なリソースを見つけ、成功することを意味するものではありません。）以下のように「受け入れ資源優先」ヘッダフィールドの構文は次のとおりです。
Accept-Resource-Priority = "Accept-Resource-Priority" HCOLON [r-value *(COMMA r-value)]
受け入れる資源優先=「受け入れる資源優先」HCOLON [r値*（COMMA r値）]
An example is given below:
例を以下に示します：
Accept-Resource-Priority: dsn.flash-override, dsn.flash, dsn.immediate, dsn.priority, dsn.routine
受け入れ-資源優先度：dsn.flash-オーバーライド、dsn.flash、dsn.immediate、dsn.priority、dsn.routine
Some administrative domains MAY choose to disable the use of the 'Accept-Resource-Priority' header for revealing too much information about that domain in responses. However, this behavior is NOT RECOMMENDED, as this header field aids in troubleshooting.
一部の管理ドメインは、応答でそのドメインについてはあまり情報を明らかにするための「受け入れ資源優先」ヘッダの使用を無効にすることができます。しかし、この動作は、トラブルシューティングで、このヘッダフィールド助剤として、推奨されません。
3.3. Usage of the 'Resource-Priority' and 'Accept-Resource-Priority' Header Fields
3.3. 「リソース優先」と「受け入れ資源-優先」ヘッダフィールドの使用方法
The following table extends the values in Table 2 of RFC 3261 [RFC3261]. (The PRACK method, labeled as PRA, is defined in [RFC3262], the SUBSCRIBE (labeled SUB) and NOTIFY (labeled NOT) methods in [RFC3265], the UPDATE (UPD) method in [RFC3311], the MESSAGE (MSG) method in [RFC3428], the REFER (REF) method in [RFC3515], the INFO (INF) method in [RFC2976], and the PUBLISH (PUB) method in [RFC3903].)
以下の表は、RFC 3261 [RFC3261]の表2の値を拡張します。 （PRAとしてラベルPRACK方法は、[RFC3262]で定義されているSUBSCRIBE（標識SUB）及び（NOT標識）[RFC3265]での方法NOTIFY、[RFC3311]でUPDATE（UPD）メソッドは、メッセージ（MSG） [RFC3428]での方法、[RFC2976]の[RFC3515]、INFO（INF）メソッドでREFER（REF）方法、及びにPUBLISH（PUB）法[RFC3903]）。
Header field where proxy INV ACK CAN BYE REG OPT PRA
----------------------------------------------------------------
Resource-Priority R amdr o o o o o o o
Accept-Resource-Priority 200 amdr o - o o o o o
Accept-Resource-Priority 417 amdr o - o o o o o
Header field where proxy SUB NOT UPD MSG REF INF PUB
----------------------------------------------------------------
Resource-Priority R amdr o o o o o o o
Accept-Resource-Priority 200 amdr o o o o o o o
Accept-Resource-Priority 417 amdr o o o o o o o
Other request methods MAY define their own handling rules; unless otherwise specified, recipients MAY ignore these header fields.
他のリクエストメソッドは、独自の処理ルールを定義してもよい（MAY）。特に指定がない限り、受信者は、これらのヘッダフィールドを無視するかもしれません。
This document also defines the "resource-priority" option tag. The behavior is described in Section 4.3, and the IANA registration is in Section 12.3.
また、このドキュメントでは、「資源優先」オプションタグを定義します。動作は4.3節で説明した、とIANA登録は、12.3節になっています。
All SIP user agents and proxy servers that support this specification share certain common behavior, which we describe below in Section 4.2. The behavior when a 'resource-priority' option tag is encountered in a 'Require' header field is described in Section 4.3. Section 4.4 describes the treatment of OPTIONS requests. The two fundamental resource contention resolution mechanisms, preemption and queueing, are described in Section 4.5. Section 4.6 explains what happens when requests fail. Behavior specific to user agent clients, servers, and proxy servers is covered in Section 4.7.
我々は4.2節で以下の記述この仕様を共有し、ある共通の動作をサポートするすべてのSIPユーザエージェントとプロキシサーバー、。 「リソースの優先度」オプションタグが「必要」ヘッダフィールドに遭遇されている動作は、セクション4.3に記載されています。 4.4節は、OPTIONS要求の治療について説明します。二つの基本的なリソースの競合解決メカニズム、プリエンプション及びキューイングは、4.5節に記載されています。 4.6節は、要求が失敗したときに何が起こるかを説明します。ユーザー・エージェント・クライアント、サーバ、およびプロキシサーバへの具体的な行動は、4.7節で覆われています。
The 'Resource-Priority' header field is potentially applicable to all SIP request messages. At a minimum, implementations of the following request types MUST support the Resource-Priority header to be in compliance with this specification:
「リソース優先」ヘッダフィールドは、すべてのSIP要求メッセージに潜在的に適用されます。最低限、次のリクエストの種類の実装は、この仕様に準拠するリソースプライオリティヘッダーをサポートしなければなりません。
o INVITE [RFC3261]
O [RFC3261]をINVITE
o ACK [RFC3261]
O ACK [RFC3261]
o PRACK [RFC3262]
お ＰらＣＫ 「ＲＦＣ３２６２」
o UPDATE [RFC3311]
O更新[RFC3311]
o REFER [RFC3515]
O [RFC3515]をREFER
Implementations SHOULD support the 'Resource-Priority' header field in the following request types:
実装は、以下の要求タイプに「資源の優先順位」ヘッダフィールドをサポートする必要があります。
o MESSAGE [RFC3428]
Oメッセージ[RFC3428]
o SUBSCRIBE [RFC3265]
O [RFC3265]をSUBSCRIBE
o NOTIFY [RFC3265]
O [RFC3265]をNOTIFY
Note that this does not imply that all implementations have to support all request methods listed.
これは、すべての実装が記載されているすべてのリクエストメソッドをサポートする必要があることを意味するものではないことに注意してください。
If a SIP element receives the 'Resource-Priority' header field in a request other than those listed above, the header MAY be ignored, according to the rules of [RFC3261].
SIP要素は上記以外の要求で「リソースプライオリティ」ヘッダフィールドを受信した場合、ヘッダは、[RFC3261]のルールによれば、無視してもよいです。
In short, an RP actor performs the following steps when receiving a prioritized request. Error behavior is described in Section 4.6.
優先要求を受信した場合要するに、RPアクターは、以下のステップを実行します。エラー動作は、4.6節に記載されています。
1. If the RP actor recognizes none of the name spaces, it treats the request as if it had no 'Resource-Priority' header field.
1. RPの俳優は、名前空間のどれもが認識しない場合、それは何の「リソース優先」ヘッダフィールドがなかったかのように、それは要求を処理します。
2. It ascertains that the request is authorized according to local policy to use the priority levels indicated. If the request is not authorized, it rejects it. Examples of authorization policies are discussed in Security Considerations (Section 11).
2.要求が示す優先レベルを使用するために、ローカルポリシーに従って許可されていることを確認します。要求が許可されていない場合、それはそれを拒否します。認可ポリシーの例としては、セキュリティ上の考慮事項（第11節）で議論されています。
3. If the request is authorized and resources are available (no congestion), it serves the request as usual. If the request is authorized but resources are not available (congestion), it either preempts other current sessions or inserts the request into a priority queue, as described in Section 4.5.
要求が承認され、リソースは（NO渋滞）利用可能である場合3.、それはいつものように、要求を提供しています。リクエストが承認さが、リソースが（混雑）は使用できませんされている場合は、他の現在のセッションを先取りいずれか、またはセクション4.5で説明したように、優先度キューに要求を挿入します。
Following standard SIP behavior, if a SIP request contains the 'Require' header field with the 'resource-priority' option tag, a SIP user agent MUST respond with a 420 (Bad Extension) if it does not support the SIP extensions described in this document. It then lists "resource-priority" in the 'Unsupported' header field included in the response.
SIPリクエストは、「リソースの優先度」オプションタグを持つ「必要」ヘッダフィールドが含まれている場合、それは、この中で説明したSIPの拡張をサポートしていない場合は、標準SIPの動作に続いて、SIPユーザエージェントは420（悪い拡張）で応じなければなりません資料。その後、レスポンスに含まれる「サポートされていない」ヘッダフィールドに「資源の優先順位」を示しています。
The use of the 'resource-priority' option tag in 'Proxy-Require' header field is NOT RECOMMENDED.
「リソースの優先度」オプションを使用することは、「プロキシ要求」ヘッダフィールド内のタグは推奨されません。
An OPTIONS request can be used to determine if an element supports the mechanism. A compliant implementation SHOULD return an 'Accept-Resource-Priority' header field in OPTIONS responses enumerating all valid resource values, but an RP actor MAY be configured not to return such values or only to return them to authorized requestors.
OPTIONS要求は、要素がメカニズムをサポートしているかどうかを判断するために使用することができます。準拠した実装では、すべての有効なリソース値を列挙OPTIONS応答で「受け入れ-資源の優先順位」をヘッダフィールドを返す必要がありますが、RPの俳優は認可要求者に返却するだけで、このような値を返すか、しないようにしてもよいです。
Following standard SIP behavior, OPTIONS responses MUST include the 'Supported' header field that includes the 'resource-priority' option tag.
標準のSIP動作に続いて、OPTIONS応答が「リソースの優先順位」オプションタグ「を含むサポートされている」ヘッダフィールドを含まなければなりません。
According to RFC 3261, Section 11, proxies that receive a request with a 'Max-Forwards' header field value of zero MAY answer the OPTIONS request, allowing a UAC to discover the capabilities of both proxy and user agent servers.
RFC 3261、セクション11によれば、ゼロの「マックス・フォワード」ヘッダフィールド値と要求を受け取るプロキシがUACの両方プロキシとユーザエージェントサーバの機能を発見することができ、OPTIONS要求に応答するかもしれません。
SIP elements may use the resource priority mechanism to modify a variety of behaviors, such as routing requests, authentication requirements, override of network capacity controls, or logging. The resource priority mechanism may influence the treatment of the request itself, the marking of outbound PSTN calls at a gateway, or of the session created by the request. (Here, we use the terms session and call interchangeably, both implying a continuous data stream between two or more parties. Sessions are established by SIP dialogs.)
SIPエレメントは、ルーティング要求、認証要求、ネットワーク容量制御のオーバーライド、またはロギングなど、行動の多様性を修正するためのリソース優先機構を使用することができます。リソース優先機構は、ゲートウェイにおいて、または要求によって作成されたセッションの発信PSTNコールのマーキング、要求自体の治療に影響を与え得ます。 （ここでは、用語のセッションを使用して、交換可能に呼び出し、両方の2つの以上の当事者間の連続データストリームを意味している。セッションはSIPダイアログによって確立されています。）
Below, we define two common algorithms, namely, preemption and priority queueing. Preemption applies only to sessions created by SIP requests, while both sessions and request handling can be subject to priority queueing. Both algorithms can sometimes be combined in the same element, although none of the namespaces described in this document do this. Algorithms can be defined for each namespace or, in some cases, can be specific to an administrative domain. Other behavior, such as request routing or network management controls, is not defined by this specification.
以下に、我々は2つの一般的なアルゴリズム、すなわち、先取りおよびプライオリティキューイングを定義します。セッションとリクエスト処理の両方プライオリティキューイングの対象となることができますがプリエンプションは、SIPリクエストによって作成されたセッションにのみ適用されます。この文書に記載された名前空間のどれもこれを実行しないものの、両方のアルゴリズムは、時々、同じ要素に組み合わせることができます。アルゴリズムは、各名前空間を定義することができたり、いくつかのケースでは、管理ドメインに特異的であることができます。そのようなリクエストルーティングまたはネットワーク管理制御のような他の動作は、この仕様で定義されていません。
Naturally, only SIP elements that understand this mechanism and the namespace and resource value perform these algorithms. Section 4.6.2 discusses what happens if an RP actor does not understand priority values contained in a request.
当然のことながら、このメカニズムと名前空間とリソースの価値を理解する唯一のSIP要素はこれらのアルゴリズムを実行します。 4.6.2は、RPの俳優が要求に含まれる優先順位の値を理解していない場合は何が起こるかを説明します。
An RP actor following a preemption policy may disrupt an existing session to make room for a higher-priority incoming session. Since sessions may require different amounts of bandwidth or a different number of circuits, a single higher-priority session may displace more than one lower-priority session. Unless otherwise noted, requests do not preempt other requests of equal priority. As noted above, the processing of SIP requests itself is not preempted. Thus, since proxies do not manage sessions, they do not perform preemption.
プリエンプションポリシー以下RPの俳優は、より高い優先度の着信セッションのための部屋を作るために既存のセッションを中断される場合があります。セッションが帯域幅または回路の異なる数の異なる量を必要とするかもしれないので、単一より高い優先度のセッションは、複数の優先度の低いセッションを移動してもよいです。特に断りのない限り、要求は、同じ優先順位の他の要求を先取りしません。上述したように、SIPリクエスト自体の処理がプリエンプトされていません。プロキシがセッションを管理していないので、このように、彼らはプリエンプションを実行しません。
[RFC4411] contains more details and examples of this behavior.
[RFC4411]は、この動作の詳細および例が含まれています。
UAS behavior for preemption is discussed in Section 4.7.2.1.
プリエンプションのためのUASの動作は、セクション4.7.2.1で説明されています。
In a priority queueing policy, requests that find no available resources are queued to the queue assigned to the priority value. Unless otherwise specified, requests are queued in first-come, first-served order. Each priority value may have its own queue, or several priority values may share a single queue. If a resource becomes available, the RP actor selects the request from the highest-priority non-empty queue according to the queue service policy. For first-come, first-served policies, the request from that queue that has been waiting the longest is served. Each queue can hold a finite number of pending requests. If the per-priority-value queue for a newly arriving request is full, the request is rejected immediately, with the status codes specified in Section 4.6.5 and Section 4.6.6. In addition, a priority queueing policy MAY impose a waiting time limit for each priority class, whereby requests that exceed a specified waiting time are ejected from the queue and a 408 (Request Timeout) failure response is returned to the requestor.
プライオリティキューイングのポリシーでは、使用可能なリソースを見つけていない要求はプライオリティ値に割り当てられたキューに格納されています。特に指定のない限り、要求は先着順順にキューイングされています。各優先順位の値は、独自のキューを有していてもよく、またはいくつかの優先順位値は、単一のキューを共有する場合があります。リソースが利用可能になった場合、RPの俳優は、キューサービスポリシーに従って、最も優先順位の高い非空のキューから要求を選択します。先着順方針について、最長のを待っているそのキューからの要求を提供しています。各キューは保留中の要求の有限数を保持することができます。新しく到着リクエストごとの優先順位の値キューがいっぱいの場合、要求は4.6.5と4.6.6で指定されたステータスコードを、即座に拒否されます。また、プライオリティキューイングポリシーは、指定された待機時間を超えた要求がキューから排出され、408（要求タイムアウト）失敗応答が要求元に返されることにより、各優先度クラスを待っている時間制限を課すことができます。
Finally, an RP actor MAY impose a global queue size limit summed across all queues and drop waiting lower-priority requests with a 408 (Request Timeout) failure response. This does not imply preemption, since the session has not been established yet.
最後に、RPの俳優は、すべてのキューにわたって合計グローバルキューサイズの制限を課し、408（リクエストタイムアウト）失敗応答で優先順位の低い要求を待って低下することがあります。セッションがまだ確立されていないので、これは、プリエンプションを意味するものではありません。
UAS behavior for queueing is discussed in Section 4.7.2.2.
キューイングのためのUASの動作は、セクション4.7.2.2で説明されています。
In this section, we describe the error behavior that is shared among multiple types of RP actors (including various instances of UAS such as trunk gateways, line gateways, and IP phones) and proxies.
このセクションでは、とプロキシ（たとえば、トランクゲートウェイ、ラインゲートウェイ、およびIP電話などUASの様々なインスタンスを含む）RP俳優、複数の種類の間で共有されるエラー動作を説明します。
A request containing a resource priority indication can fail for four reasons:
リソース優先指示を含む要求は、4つの理由で失敗することができます。
o the RP actor does not understand the priority value (Section 4.6.2),
O RPの俳優は、優先順位の値を理解していない（4.6.2項）、
o the requestor is not authenticated (Section 4.6.3),
O要求者が認証されていない（4.6.3項）、
o an authenticated requestor is not authorized to make such a request (Section 4.6.4), or
認証要求者がそのような要求（項4.6.4）を作成することを許可されていないO、もしくは
o there are insufficient resources for an authorized request (Section 4.6.5).
O許可要求（4.6.5）のための十分なリソースがあります。
We treat these error cases in the order that they typically arise in the processing of requests with Resource-Priority headers. However, this order is not mandated. For example, an RP actor that knows that a particular resource value cannot be served or queued MAY, as a matter of local policy, forgo authorization, since it would only add processing load without changing the outcome.
我々は、彼らが一般的に資源優先ヘッダを持つリクエストの処理中に発生するようにするために、これらのエラーケースを扱います。しかし、この順序が義務付けられていません。それが唯一の結果を変更することなく、処理負荷を追加することになりますので、例えば、特定のリソース値が配信またはMAYをキューに入れることができないことを知っているRPの俳優は、ローカルポリシーの問題として、承認を見送ります。
If an RP actor does not understand any of the resource values in the request, the treatment depends on the presence of the 'Require' 'resource-priority' option tag:
RPの俳優が要求におけるリソース値のいずれかを理解していない場合は、治療は「」リソースの優先度を「必要」オプションタグの存在に依存します。
1. Without the option tag, the RP actor treats the request as if it contained no 'Resource-Priority' header field and processes it with default priority. Resource values that are not understood MUST NOT be modified or deleted.
1.それは「資源の優先順位」ヘッダフィールドを含んでいなかったかのようにオプションタグがなければ、RPの俳優はリクエストを扱い、デフォルトの優先度でそれを処理します。理解されていないリソースの値を変更または削除しないでください。
2. With the option tag, it MUST reject the request with a 417 (Unknown Resource-Priority) response code.
オプションタグ2.、それは417（不明な資源優先）応答コードで要求を拒絶しなければなりません。
Making case (1) the default is necessary since otherwise there would be no way to successfully complete any calls in the case where a proxy on the way to the UAS shares no common namespaces with the UAC, but the UAC and UAS do have such a namespace in common.
そうでない場合は、正常UAS共有への途中でプロキシUACとなしの一般的な名前空間が、UACとUASは、持ってない場合、すべての呼び出しを完了するための方法がないので、ケースを作ることは（1）デフォルトが必要です共通の名前空間。
In general, as noted, a SIP request can contain more than one 'Resource-Priority' header field. This is necessary if a request needs to traverse different administrative domains, each with its own set of valid resource values. For example, the ETS namespace might be enabled for United States government networks that also support the DSN and/or DRSN namespaces for most individuals in those domains.
一般に、述べたように、SIP要求は、複数の「リソースプライオリティ」ヘッダ・フィールドを含むことができます。要求が異なる管理ドメイン、有効なリソース値の独自のセットを持つ各を横断する必要がある場合、これが必要です。例えば、ETS名前空間はまた、これらのドメインのほとんどの個人のためのDSNおよび/またはDRSN名前空間をサポートする米国政府のネットワークのために有効にされる可能性があります。
A 417 (Unknown Resource-Priority) response MAY, according to local policy, include an 'Accept-Resource-Priority' header field enumerating the acceptable resource values.
417（未知の資源優先）応答MAYは、ローカルポリシーに従って、許容されるリソース値を列挙ヘッダフィールド「資源優先受け入れ」を含みます。
If the request is not authenticated, a 401 (Unauthorized) or 407 (Proxy Authentication Required) response is returned in order to allow the requestor to insert appropriate credentials.
要求が認証されない場合、（不正）401または407（プロキシ認証が必要）応答は、要求者が適切な資格情報を挿入することを可能にするために戻されます。
If the RP actor receives an authenticated request with a namespace and priority value it recognizes but the originator is not authorized for that level of service, the element MUST return a 403 (Forbidden) response.
RPの俳優は、それが認識した名前空間と優先順位の値で認証要求を受信するが、発信元がサービスのそのレベルのために許可されていない場合は、要素は403（禁止）応答を返さなければなりません。
Insufficient resource conditions can occur on proxy servers and user agent servers, typically trunk gateways, if an RP actor receives an authorized request, has insufficient resources, and the request neither preempts another session nor is queued. A request can fail because the RP actor has either insufficient processing capacity to handle the SIP request or insufficient bandwidth or trunk capacity to establish the requested session for session-creating SIP requests.
RPの俳優が、許可された要求を受け取るリソースが不足していて、要求は別のセッションを先取りもなく、キューに入れもされていない場合には不十分なリソース条件は、プロキシサーバとユーザエージェントサーバ、通常、トランクゲートウェイ上で発生する可能性があります。 RPの俳優は、SIPリクエストまたはセッションの作成SIPリクエストのために要求されたセッションを確立するのに十分な帯域幅やトランクの容量を処理するのに十分な処理能力のいずれかを持っているため、要求が失敗する可能性があります。
If the request fails because the RP actor cannot handle the signaling load, the RP actor responds with 503 (Service Unavailable).
RPの俳優は、シグナリング負荷を処理できないため、要求が失敗した場合、RPの俳優は、503（サービス利用不可）で応答します。
If there is not enough bandwidth, or if there is an insufficient number of trunks, a 488 (Not Acceptable Here) response indicates that the RP actor is rejecting the request due to media path availability, such as insufficient gateway resources. In that case, [RFC3261] advises that a 488 response SHOULD include a 'Warning' header field with a reason for the rejection; warning code 370 (Insufficient Bandwidth) is typical.
そこに十分な帯域幅がない場合、またはトランクの数が不足がある場合には、488（ここでは許容できない）応答は、RPの俳優は、このような不十分なゲートウェイリソースとしてメディアパスの利用可能性、のために、要求を拒否していることを示している。場合その場合には、[RFC3261]は、488応答は、拒絶の理由と「警告」ヘッダフィールドを含むべきであることを助言します。警告コード370（不十分な帯域幅）が典型的です。
For systems implementing queueing, if the request is queued, the UAS will return 408 (Request Timeout) if the request exceeds the maximum configured waiting time in the queue.
要求がキューイングされている場合、要求がキューに待機時間設定最大値を超えた場合、キューイングを実現するシステムの場合、UASは、（要求タイムアウト）408を返します。
Resource contention also occurs when a call request arrives at a UAS that is unable to accept another call, because the UAS either has just one line appearance or has active calls on all line appearances. If the call request indicates an equal or lower priority value when compared to all active calls present on the UAS, the UAS returns a 486 (Busy here) response.
コール要求はUASがちょうど1行の外観を持っているか、すべてのラインアピアランス上のアクティブコールを持っているいずれかのために、別のコールを受け入れることができませんUASに到着したとき、リソースの競合が発生します。 UASに存在するすべてのアクティブコールと比較した場合、通話要求は、同じまたは低い優先度の値を示す場合、UASは486（ここでBUSY）応答を返します。
If the request is queued instead, the UAS will return a 408 (Request Timeout) if the request exceeds the maximum configured waiting time in the device queue.
要求が代わりにキューイングされている場合は、要求がデバイスキューに待機時間設定された最大値を超えた場合、UASは408（要求タイムアウト）を返します。
If a proxy gets 486 (Busy Here) responses on all branches, it can then return a 600 (Busy Everywhere) response to the caller.
プロキシは、すべての枝に486（ここで忙しい）の応答を取得した場合、それは、呼び出し元に600（どこでも通話中）応答を返すことができます。
SIP UACs supporting this specification MUST be able to generate the 'Resource-Priority' header field for requests that require elevated resource access priority. As stated previously, the UAC SHOULD be able to generate more than one resource value in a single SIP request.
この仕様をサポートするSIP求めるUACは上昇し、リソースへのアクセス優先順位を必要とする要求の「リソースプライオリティ」ヘッダフィールドを生成できなければなりません。先に述べたように、UACは、単一のSIP要求における複数のリソース値を生成することができるべきです。
Upon receiving a 417 (Unknown Resource-Priority) response, the UAC MAY attempt a subsequent request with the same or different resource value. If available, it SHOULD choose authorized resource values from the set of values returned in the 'Accept-Resource-Priority' header field.
417（未知の資源優先度）応答を受信すると、UACは、同じまたは異なるリソース値を持つ後続の要求を試行してもよい（MAY）。利用可能ならば、それは受け入れ資源優先 "ヘッダフィールドに返される値のセットからの認可リソース値を選択する必要があります。
A UAC that requests a priority value that may cause preemption MUST understand a Reason header field in the BYE request explaining why the session was terminated, as discussed in [RFC4411].
[RFC4411]で議論するようにプリエンプションは、セッションが終了した理由を説明するBYE要求に理由ヘッダーフィールドを理解しなければならない恐れがあり、優先度の値を要求するUAC。
By standard SIP protocol rules, a UAC MUST be prepared to receive a 182 (Queued) response from an RP actor that is currently at capacity, but that has put the original request into a queue. A UAC MAY indicate this queued status to the user by some audio or visual indication to prevent the user from interpreting the call as having failed.
標準のSIPプロトコル規則によって、UACは、容量で現在RPアクターから182（キュー）応答を受信するように準備しなければなりませんが、それはキューに元の要求を入れました。 UACは、これが失敗したとして呼び出しを解釈するからユーザーを防ぐために、いくつかのオーディオまたは視覚的に表示することによって、ユーザに状況をキューに入れられ示すかもしれ。
The precise effect of the 'Resource-Priority' indication depends on the type of UAS, the namespace, and local policy.
「リソース優先」表示の正確な効果は、UASの種類、名前空間、およびローカルポリシーに依存します。
A UAS compliant with this specification MUST terminate a session established with a valid namespace and lower-priority value in favor of a new session set up with a valid namespace and higher relative priority value, unless local policy has some form of call-waiting capability enabled. If a session is terminated, the BYE method is used with a 'Reason' header field indicating why and where the preemption took place.
ローカルポリシーは、コールウェイティング機能のいくつかの形式が有効になっていない限り、この仕様に準拠UASは、有効な名前空間と高い相対優先順位値を設定し、新しいセッションを優先して、有効な名前空間と優先順位の低い値で確立されたセッションを終えなければなりません。セッションが終了した場合、BYEメソッドは、なぜ、どこでプリエンプションが行われた示す「理由」ヘッダフィールドで使用されています。
Implementors have a number of choices in how to implement preemption at IP phones with multiple line presences, i.e., with devices that can handle multiple simultaneous sessions. Naturally, if that device has exhausted the number of simultaneous sessions, one of the sessions needs to be replaced. If the device has spare sessions, an implementation MAY choose to alert the callee to the arrival of a higher-priority call. Details may also be set by local or namespace policy.
実装者は、複数の同時セッションを処理できる機器で、すなわち、複数の回線のプレゼンスとIP電話でプリエンプションを実装する方法における選択肢の数を持っています。そのデバイスは、同時セッション数を使い果たした場合は当然のことながら、セッションの1つを交換する必要があります。デバイスは、予備のセッションを持っている場合、実装は、優先度の高いコールの到着に呼び出し先に警告するために選ぶかもしれません。詳細は、ローカルまたは名前空間ポリシーで設定することができます。
[RFC4411] provides additional information in the case of purposeful or administrative termination of a session by including the Reason header in the BYE message that states why the BYE was sent (in this case, a preemption event). The mechanisms in that document allow indication of where the termination occurred ('at the UA', 'within a reservation', 'at a IP/PSTN gateway') and include call flow examples of each reason.
[RFC4411]はBYE（この場合、プリエンプションイベントで）送信された理由を述べてBYEメッセージにおけるReasonヘッダを含むことにより、セッションの意図または管理終了の場合には、追加情報を提供します。その文書に記載されているメカニズムは、（「IP / PSTNゲートウェイに」、「予約内」、「UAで」）終了が発生した場所の表示を可能にし、各理由のコールフローの例を含みます。
A UAS compliant with this specification SHOULD generate a 182 (Queued) response if that element's resources are busy, until it is able to handle the request and provide a final response. The frequency of such provisional messages is governed by [RFC3261].
その要素のリソースがビジー状態であれば、要求を処理し、最終的な応答を提供することができるまで、この仕様に準拠したUASのは、182（キュー）応答を生成する必要があります。そのような仮メッセージの頻度は、[RFC3261]によって支配されます。
SIP proxies MAY ignore the 'Resource-Priority' header field. SIP proxies MAY reject any unauthenticated request bearing that header field.
SIPプロキシは、「資源の優先順位」ヘッダーフィールドを無視してもよい（MAY）。 SIPプロキシはそのヘッダーフィールドを保有する任意の認証されていない要求を拒否する可能性があります。
When the 'Require' header field is included in a message, it ensures that in parallel forking, only branches that support the resource-priority mechanism succeed.
「要求」ヘッダフィールドがメッセージに含まれている場合、それは並列フォークにおいて、リソース優先順位機構をサポートする唯一の分岐が成功することを保証します。
If S/MIME encapsulation is used according to Section 23 of RFC 3261, special considerations apply. As tabulated in Section 3.3, the 'Resource-Priority' header field can be modified by proxies and thus is exempted from the integrity checking described in Section 23.4.1.1 of RFC 3261. Since it may need to be inspected or modified by proxies, the header field MUST also be placed in the "outer" message if the UAC would like proxy servers to be able to act on the header information. Similar considerations apply if parts of the message are integrity protected or encrypted as described in [RFC3420].
S / MIMEのカプセル化は、RFC 3261のセクション23に応じて使用される場合は、特別な考慮事項が適用されます。 3.3節にまとめたように、「リソース優先」ヘッダーフィールドはプロキシによって変更することができ、したがって、それは、プロキシによって検査または改変する必要があるかもしれないので、RFC 3261のセクション23.4.1.1に記載の完全性検査を免除されていますUACは、プロキシサーバは、ヘッダ情報に基づいて行動できるようにしたい場合ヘッダフィールドは、「外部」メッセージに置かなければなりません。 [RFC3420]に記載されているように、メッセージの部分が完全性保護または暗号化されている場合、同様の考察が当てはまります。
If S/MIME is not used, or if the 'Resource-Priority' header field is in the "outer" header, SIP proxies MAY downgrade or upgrade the 'Resource-Priority' of a request or insert a new 'Resource-Priority' header if allowed by local policy.
S / MIMEを使用していない、または「リソース優先」ヘッダーフィールドが「外側」のヘッダーにある場合、SIPプロキシは、ダウングレードまたはリクエストの「資源の優先順位」をアップグレードするか、新しい「資源の優先順位」を挿入することができる場合ローカルポリシーによって許可された場合にヘッダー。
If a stateful proxy has authorized a particular resource priority level, and if it offers differentiated treatment to responses containing resource priority levels, the proxy SHOULD ignore any higher value contained in responses, to prevent colluding user agents from artificially raising the priority level.
ステートフルプロキシは、特定のリソースの優先度を許可しており、それはリソース優先順位レベルを含む応答に分化した治療を提供している場合、プロキシは、人工的に優先度を上げるから、ユーザエージェントを共謀防止するために、応答に含まれる任意の高い値を無視するかどうか。
A SIP proxy MAY use the 'Resource-Priority' indication in its routing decisions, e.g., to retarget to a SIP node or SIP URI that is reserved for a particular resource priority.
SIPプロキシは、特定のリソースの優先順位のために予約されているSIPノードまたはSIP URIにリターゲットするために、例えば、そのルーティング決定に「リソース優先」指示を使用するかもしれません。
There are no special considerations for proxies when forking requests containing a resource priority indication.
リソースの優先度表示を含むリクエストをフォークプロキシの特別な考慮事項はありません。
Otherwise, the proxy behavior is the same as for user agent servers described in Section 4.7.2.
それ以外の場合は、プロキシの動作は、第4.7.2項で説明したユーザエージェントサーバの場合と同じです。
In some cases, the RP actor may not be able to authenticate the requestor or determine whether an authenticated user is authorized to make such a request. In these circumstances, the SIP entity may avail itself of general SIP mechanisms that are not specific to this application. The authenticated identity management mechanism [RFC3893] allows a third party to verify the identity of the requestor and to certify this towards an RP actor. In networks with mutual trust, the SIP-asserted identity mechanism [RFC3325] can help the RP actor determine the identity of the requestor.
いくつかのケースでは、RPの俳優は、要求を認証したり、認証されたユーザは、このような要求を行うことを許可されているかどうかを決定することができない場合があります。このような状況では、SIPエンティティは、このアプリケーションに固有でない一般的なSIPメカニズム自体が役に立つことができます。認証されたアイデンティティ管理メカニズム[RFC3893]は第三者が要求者の身元を確認し、RPの俳優に向けて、これを証明することができます。相互信頼とネットワークでは、SIP-アサートアイデンティティメカニズム[RFC3325]はRPの俳優は、要求者の身元を特定するのに役立ちます。
The resource priority mechanism described in this document is fully backwards compatible with SIP systems following [RFC3261]. Systems that do not understand the mechanism can only deliver standard, not elevated, service priority. User agent servers and proxies can ignore any 'Resource-Priority' header field just like any other unknown header field and then treat the request like any other request. Naturally, the request may still succeed.
この文書に記載されたリソースの優先順位機構は、次のSIPシステム[RFC3261]と完全に下位互換性があります。メカニズムを理解していないシステムでは、標準、上昇していない、サービスの優先順位を提供することができます。ユーザー・エージェント・サーバーやプロキシは、他の未知のヘッダーフィールドのような任意の「リソース優先」ヘッダフィールドを無視して、他の要求のような要求を扱うことができます。当然のことながら、要求はまだ成功することがあります。
The SDP message body and the BYE and ACK exchanges are the same as in RFC 3665 [RFC3665] and are omitted for brevity.
SDPメッセージ本体とBYEとACK交換は、RFC 3665 [RFC3665]と同じであり、簡潔にするために省略されています。
User A User B
| |
| INVITE F1 |
|----------------------->|
| 180 Ringing F2 |
|<-----------------------|
| |
| 200 OK F3 |
|<-----------------------|
| ACK F4 |
|----------------------->|
| Both Way RTP Media |
|<======================>|
| |
In this scenario, User A completes a call to User B directly. The call from A to B is marked with a resource priority indication.
このシナリオでは、ユーザーAは、直接ユーザBへの呼び出しを完了します。 AからBへの呼び出しは、リソースの優先度表示とマークされています。
F1 INVITE User A -> User B
F1 INVITEユーザーA - >ユーザB
INVITE sip:UserB@biloxi.example.com SIP/2.0 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 Max-Forwards: 70 From: BigGuy <sip:UserA@atlanta.example.com>;tag=9fxced76sl To: LittleGuy <sip:UserB@biloxi.example.com> Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 INVITE Resource-Priority: dsn.flash Contact: <sip:UserA@client.atlanta.example.com;transport=tcp> Content-Type: application/sdp Content-Length: ...
SIP INVITE：UserB@biloxi.example.comをSIP / 2.0経由：SIP / 2.0 / TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9マックス・フォワード：持つbigguy <SIP：UserA@atlanta.exampleから70。コム>;タグ= 9fxced76slへ：LittleGuy <SIP：UserB@biloxi.example.com>コール-IDを：3848276298220188511@atlanta.example.comのCSeq：dsn.flash連絡先：<SIP：ユーザーA @クライアント資源優先順位1 INVITE .atlanta.example.com;運輸= TCP>のContent-Type：アプリケーション/ SDPコンテンツの長さ：...
...
。。。
F2 180 Ringing User B -> User A
F2 180リンギングユーザB - >ユーザA
SIP/2.0 180 Ringing Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 ;received=192.0.2.101 From: BigGuy <sip:UserA@atlanta.example.com>;tag=9fxced76sl To: LittleGuy <sip:UserB@biloxi.example.com>;tag=8321234356 Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 INVITE Contact: <sip:UserB@client.biloxi.example.com;transport=tcp> Content-Length: 0
SIP / 2.0 180リンギングのVia：SIP / 2.0 / TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9;から= 192.0.2.101を受信：持つbigguy <SIP：UserA@atlanta.example.com>;タグ= 9fxced76slに：LittleGuy <SIP：UserB@biloxi.example.com>;タグは= 8321234356コールID：3848276298220188511@atlanta.example.comのCSeq：1連絡先をINVITE：<SIP：UserB@client.biloxi.example.com;輸送= TCP >コンテンツの長さ：0
F3 200 OK User B -> User A
F3 200 OKユーザB - >ユーザA
SIP/2.0 200 OK Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 ;received=192.0.2.101 From: BigGuy <sip:UserA@atlanta.example.com>;tag=9fxced76sl To: LittleGuy <sip:UserB@biloxi.example.com>;tag=8321234356 Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 INVITE Contact: <sip:UserB@client.biloxi.example.com;transport=tcp> Content-Type: application/sdp Content-Length: ...
SIP / 2.0 200 OK経由：SIP / 2.0 / TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9;から= 192.0.2.101を受け取っ：持つbigguy <SIP：UserA@atlanta.example.com>;タグ= 9fxced76slへ：LittleGuy <SIP：UserB@biloxi.example.com>;タグは= 8321234356コールID：3848276298220188511@atlanta.example.comのCSeq：1連絡先をINVITE：<SIP：UserB@client.biloxi.example.com;輸送= TCP >のContent-Type：アプリケーション/ SDPコンテンツの長さ：...
...
。。。
In this example, the receiving UA does not understand the "dsn" namespace and thus returns a 417 (Unknown Resource-Priority) status code. We omit the message details for messages F5 through F7, since they are essentially the same as in the first example.
この例では、受信UAは、「DSN」の名前空間を理解するため、417（未知の資源優先）ステータスコードを返していません。彼らは基本的に最初の例と同じであるので、我々は、F7を介してメッセージのF5のためのメッセージの詳細を省略します。
User A User B
| |
| INVITE F1 |
|----------------------->|
| 417 R-P failed F2 |
|<-----------------------|
| ACK F3 |
|----------------------->|
| |
| INVITE F4 |
|----------------------->|
| 180 Ringing F5 |
|<-----------------------|
| 200 OK F6 |
|<-----------------------|
| ACK F7 |
|----------------------->|
| |
| Both Way RTP Media |
|<======================>|
F1 INVITE User A -> User B
F1 INVITEユーザーA - >ユーザB
INVITE sip:UserB@biloxi.example.com SIP/2.0 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 Max-Forwards: 70 From: BigGuy <sip:UserA@atlanta.example.com>;tag=9fxced76sl To: LittleGuy <sip:UserB@biloxi.example.com> Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 INVITE Require: resource-priority Resource-Priority: dsn.flash Contact: <sip:UserA@client.atlanta.example.com;transport=tcp>
SIP INVITE：UserB@biloxi.example.comをSIP / 2.0経由：SIP / 2.0 / TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9マックス・フォワード：持つbigguy <SIP：UserA@atlanta.exampleから70。コム>;、タグ= 9fxced76sl：LittleGuy <SIP：UserB@biloxi.example.com>コールID：3848276298220188511@atlanta.example.comのCSeq：1 INVITE要求：リソースプライオリティの資源優先度：dsn.flashとの接触：< SIP：UserA@client.atlanta.example.com;運輸= TCP>
Content-Type: application/sdp Content-Length: ...
コンテンツタイプ：アプリケーション/ SDPコンテンツの長さ：...
...
。。。
F2 417 Resource-Priority failed User B -> User A
F2 417リソース優先失敗したユーザB - >ユーザA
SIP/2.0 417 Unknown Resource-Priority Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 ;received=192.0.2.101 From: BigGuy <sip:UserA@atlanta.example.com>;tag=9fxced76sl To: LittleGuy <sip:UserB@biloxi.example.com>;tag=8321234356 Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 INVITE Accept-Resource-Priority: q735.0, q735.1, q735.2, q735.3, q735.4 Contact: <sip:UserB@client.biloxi.example.com;transport=tcp> Content-Type: application/sdp Content-Length: 0
SIP / 2.0 417不明なリソース優先経由：SIP / 2.0 / TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9;から= 192.0.2.101を受け取っ：持つbigguy <SIP：UserA@atlanta.example.com>;タグ=へ9fxced76sl：LittleGuy <SIP：UserB@biloxi.example.com>;タグ= 8321234356のCall-ID：3848276298220188511@atlanta.example.comのCSeq：1 INVITEのAccept-資源優先順位：q735.0、q735.1、q735 0.2、q735.3、q735.4連絡先：<SIP：UserB@client.biloxi.example.com;運輸= TCP>のContent-Type：アプリケーション/ SDPのContent-Length：0
F3 ACK User A -> User B
F3 ACKユーザーA - >ユーザB
ACK sip:UserB@biloxi.example.com SIP/2.0 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bd5 Max-Forwards: 70 From: BigGuy <sip:UserA@atlanta.example.com>;tag=9fxced76sl To: LittleGuy <sip:UserB@biloxi.example.com>;tag=8321234356 Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 ACK Content-Length: 0
ACKのSIP：UserB@biloxi.example.com SIP / 2.0経由：SIP / 2.0 / TCP client.atlanta.example.com:5060;branch=z9hG4bK74bd5マックス・フォワード：70から：持つbigguy <SIP：UserA@atlanta.example。コム>;タグ= 9fxced76slへ：LittleGuy <SIP：UserB@biloxi.example.com>;タグは= 8321234356のCall-ID：3848276298220188511@atlanta.example.comのCSeq：1個のACKのContent-Length：0
F4 INVITE User A -> User B
F4 INVITEユーザーA - >ユーザB
INVITE sip:UserB@biloxi.example.com SIP/2.0 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 Max-Forwards: 70 From: BigGuy <sip:UserA@atlanta.example.com>;tag=9fxced76sl To: LittleGuy <sip:UserB@biloxi.example.com> Call-ID: 3848276298220188511@atlanta.example.com CSeq: 2 INVITE Require: resource-priority Resource-Priority: q735.3 Contact: <sip:UserA@client.atlanta.example.com;transport=tcp>
SIP INVITE：UserB@biloxi.example.comをSIP / 2.0経由：SIP / 2.0 / TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9マックス・フォワード：持つbigguy <SIP：UserA@atlanta.exampleから70。コム>;タグ= 9fxced76slへ：LittleGuy <SIP：UserB@biloxi.example.com>は、コールIDを：3848276298220188511@atlanta.example.comのCSeq：2は必要INVITE：リソースプライオリティの資源優先度：q735.3問い合わせ：< SIP：UserA@client.atlanta.example.com;運輸= TCP>
Content-Type: application/sdp Content-Length: ... ...
コンテンツタイプ：アプリケーション/ SDPのContent-Length：... ...
A single SIP request MAY contain resource values from multiple namespaces. As noted earlier, an RP actor disregards all namespaces it does not recognize. This specification only addresses the case where an RP actor then selects one of the remaining resource values for processing, usually choosing the one with the highest relative priority.
単一SIPリクエストは、複数の名前空間からのリソース値が含まれる場合があります。先に述べたように、RPの俳優は、それが認識されないすべての名前空間を無視します。この仕様は、RPアクターは、次いで通常最高相対的な優先度を持つものを選択し、処理のために残りのリソースのいずれかの値を選択した場合に対処します。
If an RP actor understands multiple namespaces, it MUST create a local total ordering across all resource values from these namespaces, maintaining the relative ordering within each namespace. It is RECOMMENDED that the same ordering be used across an administrative domain. However, there is no requirement that such ordering be the same across all administrative domains.
RPの俳優は、複数の名前空間を理解している場合、それはそれぞれの名前空間内の相対的な順序を維持し、これらの名前空間からのすべてのリソース値を越えローカル全順序を作成する必要があります。同じ順序付けは、管理ドメイン全体で使用することを推奨しています。しかし、そのような順序は、すべての管理ドメイン間で同じにする必要はありません。
Below are a set of examples of an RP actor that supports two namespaces, foo and bar. Foo's priority-values are 3 (highest), then 2, and then 1 (lowest), and bar's priority-values are C (highest), then B, and then A (lowest).
以下は、2つの名前空間をサポートしてRPの俳優の例のセット、fooとバーがあります。 FOOの優先度値は3（最高）、次いで2、次いで1（最低）であり、バーの優先順位値は、次いでC（最高）、B、及び（最低）です。
Below are five lists of acceptable priority orders the SIP element may use:
以下は、SIP要素が使用できる許容可能な優先順位の5リストは以下のとおりです。
Foo.3 Foo.3 Bar.C (highest priority)
Foo.2 Bar.C Foo.3
Foo.1 or Foo.2 or Foo.2
Bar.C Bar.B Foo.1
Bar.B Foo.1 Bar.B
Bar.A Bar.A Bar.A (lowest priority)
Bar.C (highest priority) Foo.3 Bar.B (both treated with equal priority (FIFO)) or Foo.2 Bar.A (both treated with equal priority (FIFO)) Foo.1 (lowest priority)
bar.cに（最高優先度）Foo.3 Bar.B（両方が同じ優先順位（FIFO）で処理した）またはFoo.2 Bar.A（両方が同じ優先順位で処理し（FIFO））はfoo.1（最低優先度）
Bar.C (highest priority) Foo.3 or Foo.2 Foo.1 (lowest priority)
bar.cに（最優先）Foo.3またはFoo.2はfoo.1（最低の優先順位）
In the last example above, Bar.A and Bar.B are ignored.
上記の最後の例では、Bar.AとBar.Bは無視されます。
Based on the priority order of the namespaces above, the following combinations are examples of orderings that are NOT acceptable and MUST NOT be configurable:
上記の名前空間の優先順位に基づいて、次の組み合わせが許容されていないと設定しているはずがありません順序の例です。
Example 1 Example 2 Example 3
--------- --------- ---------
Foo.3 Foo.3 Bar.C
Foo.2 Bar.A Foo.1
Foo.1 or Foo.2 or Foo.3
Bar.C Bar.B Foo.2
Bar.A Foo.1 Bar.A
Bar.B Bar.C Bar.B
Example 4
---------
Bar.C
Foo.1 Bar.B
or Foo.3 Bar.A
Foo.2
These examples are invalid since the following global orderings are not consistent with the namespace-internal order:
次のグローバル順序が名前空間内部の順序と一致していないため、これらの例は無効です。
o In Example 1, Bar.A is ordered higher than Bar.B.
O実施例1では、Bar.AはBar.B.より高く順序付けされます
o In Example 2, Bar.A is ordered higher than Bar.B and Bar.C.
O実施例2では、Bar.AはBar.BとBar.C.より高く順序付けされます
o In Example 3, Foo.1 is ordered higher than Foo.2 and Foo.3.
O実施例3において、はfoo.1はFoo.2とFoo.3よりも高くなっております。
o In Example 4, Foo.1 is ordered higher than Foo.3 and Foo.2.
O実施例4において、はfoo.1はFoo.3とFoo.2よりも高くなっております。
Organizations considering the use of the Resource-Priority header field should investigate whether an existing combination of namespace and priority-values meets their needs. For example, emergency first responders around the world are discussing utilizing this mechanism for preferential treatment in future networks. Jurisdictions SHOULD attempt to reuse existing IANA registered namespaces where possible, as a goal of this document is not to have unique namespaces per jurisdiction serving the same purpose, with the same usage of priority levels. This will greatly increase interoperability and reduce development time, and probably reduce future confusion if there is ever a need to map one namespace to another in an interworking function.
リソース優先度のヘッダフィールドの使用を検討する組織は、名前空間と優先順位値の既存の組み合わせが自分のニーズを満たしているかどうかを調べる必要があります。例えば、世界中の緊急最初の応答は、将来のネットワークでの優遇措置については、この仕組みを利用することが議論されています。このドキュメントの目標は、同じ目的を果たす管轄ごとに一意の名前空間を持つことではないとの司法管轄地域では、優先レベルの同じ使用して、可能な限り既存のIANA登録された名前空間を再利用しようとすべきです。これは、大幅に相互運用性を高め、開発時間を短縮し、インターワーキング機能に別の名前空間をマッピングする必要がこれまでに存在する場合、おそらく将来の混乱を軽減します。
Below, we describe the steps necessary to register a new namespace.
以下に、私たちは、新しい名前空間を登録するために必要な手順を説明します。
A new namespace MUST be defined in a Standards Track RFC, following the 'Standards Action' policy in [RFC2434], and MUST include the following facets:
新しい名前空間は、[RFC2434]の「標準化アクション」ポリシー以下、標準化過程RFCで定義する必要があり、かつ以下のファセットを含める必要があります。
o It must define the namespace label, a unique namespace label within the IANA registry for the SIP Resource-Priority header field.
Oそれは名前空間のラベル、SIPリソースプライオリティヘッダーフィールドのIANAレジストリ内で一意の名前空間のラベルを定義する必要があります。
o It must enumerate the priority levels (i.e., 'r-priority' values) the namespace is using. Note that only finite lists are permissible, not unconstrained integers or tokens, for example.
Oそれは、ネームスペースが使用している優先度（すなわち、R「優先度」値）を列挙しなければなりません。唯一の有限のリストには、例えば、許容、拘束されていないではない整数またはトークンであることに注意してください。
o The priority algorithm (Section 4.5), identifying whether the namespace is to be used with priority queueing ("queue") or preemption ("preemption"). If queueing is used, the namespace MAY indicate whether normal-priority requests are queued. If there is a new "intended algorithm" other than preemption or priority queueing, the algorithm must be described, taking into account all RP actors (UAC, UAS, proxies).
優先アルゴリズム（セクション4.5）O、名前空間は優先キューイング（「キュー」）または先取り（「先取り」）で使用されるかを識別する。キューイングを使用する場合、名前空間は、通常の優先順位の要求がキューイングされているか否かを示すことができます。先取りまたはプライオリティキューイング以外の新しい「意図アルゴリズム」がある場合、アルゴリズムは、アカウントのすべてのRPの俳優（UAC、UAS、プロキシ）を考慮して、説明しなければなりません。
o A namespace may either reference an existing list of priority values or define a new finite list of priority values in relative priority order for IANA registration within the sip-parameters Resource-Priority priority-values registry. New priority-values SHOULD NOT be added to a previously IANA-registered list associated with a particular namespace, as this may cause interoperability problems. Unless otherwise specified, it is assumed that all priority values confer higher priority than requests without a priority value.
名前空間は優先順位値の既存のリストを参照またはSIPパラメータリソース優先優先値レジストリ内のIANA登録の相対的な優先順位に優先順位値の新たな有限のリストを定義することができるいずれかのO。これは、相互運用性の問題を引き起こす可能性として、新しい優先順位値は、特定の名前空間に関連付けられた以前にIANA登録リストに追加しないでください。特に指定しない限り、すべての優先順位の値が優先順位の値なしの要求よりも高い優先順位を与えることが想定されます。
o Any new SIP response codes unique to this new namespace need to be explained and registered.
Oこの新しい名前空間に固有のすべての新しいSIP応答コードを説明して登録する必要があります。
o The reference document must specify and describe any new Warning header field warn-codes (RFC 3261, Section 27.2).
O参考文献を指定し、任意の新しい警告ヘッダーフィールド警告・コード（RFC 3261、セクション27.2）を記述しなければなりません。
o The document needs to specify a new row for the following table that summarizes the features of the namespace and is included into IANA Resource-Priority Namespace registration:
O文書は、名前空間の機能をまとめたものとIANAリソースプライオリティネームスペース登録に含まれている次の表に新しい行を指定する必要があります。
Intended New New resp.
Namespace Levels algorithm warn-code code Reference
--------- ------ ---------------- --------- -------- ---------
<label> <# of <preemption <new warn <new resp. <RFC>
levels> or queue> code> code>
If information on new response codes, rejection codes, or error behaviors is omitted, it is to be assumed that the namespace defines no new parameters or behaviors.
新しい応答コード、拒否コード、またはエラーの行動に関する情報が省略された場合、それは名前空間が新しいパラメータや動作を定義しないと仮定することです。
This specification defines five unique namespaces below: DSN, DRSN, Q735, ETS, and WPS, constituting their registration with IANA. Each IANA registration contains the facets defined in Section 9. For recognizability, we label the namespaces in capital letters, but note that namespace names are case insensitive and are customarily rendered as lowercase in protocol requests.
IANAで自分の登録を構成する、DSN、DRSN、Q735、ETS、およびWPS：この仕様は以下の5つのユニークな名前空間を定義します。各IANA登録が認識性については、セクション9で定義されたファセットを含んでいる、我々は、大文字で名前空間にラベルを付けますが、その名前空間名は大文字小文字を区別しないで、通例プロトコル要求で小文字としてレンダリングされている注意してください。
The DSN namespace comes from the name of a US government network called "The Defense Switched Network".
DSNの名前空間は「防衛交換ネットワーク」と呼ばれる米国政府のネットワークの名前から来ています。
The DSN namespace has a finite list of relative priority-values, listed below from lowest priority to highest priority:
DSNの名前空間は、最優先に最低の優先順位から、下記にリストされた、相対的な優先順位値の有限リストがあります：
(lowest) dsn.routine dsn.priority dsn.immediate dsn.flash (highest) dsn.flash-override
（最低）dsn.routine dsn.priority dsn.immediate dsn.flash（最高）dsn.flashオーバーライド
The DSN namespace uses the preemption algorithm (Section 4.5.1).
DSNの名前空間は、先取アルゴリズム（セクション4.5.1）を使用しています。
The DRSN namespace comes from the name of a US government network, called "The Defense RED Switched Network".
DRSN名前空間は「国防RED交換ネットワーク」と呼ばれる米国政府のネットワークの名前から来ています。
The DRSN namespace defines the following resource values, listed from lowest priority to highest priority:
DRSN名前空間は、最低の優先度から最も高い優先度にリストされた次のリソース値を定義します。
(lowest) drsn.routine drsn.priority drsn.immediate drsn.flash drsn.flash-override (highest) drsn.flash-override-override
（最低）drsn.routine drsn.priority drsn.immediate drsn.flash drsn.flashオーバーライド（最高）drsn.flashオーバーライドオーバーライド
The DRSN namespace uses the preemption algorithm (Section 4.5.1).
DRSN名前空間は、先取アルゴリズム（セクション4.5.1）を使用しています。
The DRSN namespace differs in one algorithmic aspect from the DSN and Q735 namespaces. The behavior for the 'flash-override-override' priority value differs from the other values. Normally, requests do not preempt those of equal priority, but a newly arriving 'flash-override-override' request will displace another one of equal priority if there are insufficient resources. This can also be expressed as saying that 'flash-override-override' requests defend themselves as 'flash-override' only.
DRSN名前空間には、DSNおよびQ735の名前空間から1つのアルゴリズム的様相が異なります。 「フラッシュオーバーライドオーバーライド」の行動の優先順位の値が他の値とは異なります。通常、要求は、同じ優先順位のそれらを先取りしませんが、十分なリソースがある場合は、新たに到着した「フラッシュ・オーバーライド・オーバーライドの要求は、同じ優先順位の別のものを置換します。これはまた、「フラッシュオーバーライドオーバーライドの要求のみが「フラッシュ・オーバーライド」として自分自身を守ることを言うように表現することができます。
Q.735.3 [Q.735.3] was created to be a commercial version of the operationally equivalent DSN specification for Multi-Level Precedence and Preemption (MLPP). The Q735 namespace is defined here in the same manner.
Q.735.3 [Q.735.3]マルチレベル優先順位およびプリエンプション（MLPP）のための操作上の等価DSN仕様の商用版であるために作成されました。 Q735名前空間は同じように、ここで定義されています。
The Q735 namespace defines the following resource values, listed from lowest priority to highest priority:
Q735名前空間は、最低の優先度から最も高い優先度にリストされた次のリソース値を定義します。
(lowest) q735.4 q735.3 q735.2 q735.1 (highest) q735.0
（最低）q735.4のq735.3のq735.2 q735.1（最高）q735.0
The Q735 namespace operates according to the preemption (Section 4.5.1) algorithm.
Q735名前空間は、プリエンプション（4.5.1項）アルゴリズムに従って動作します。
The ETS namespace derives its name indirectly from the name of the US government telecommunications service, called "Government Emergency Telecommunications Service" (or GETS), though the organization responsible for the GETS service chose the acronym "ETS" for its GETS over IP service, which stands for "Emergency Telecommunications Service".
GETSサービスを担当する組織は、IPサービスを乗り越えるそのために頭文字「ETS」を選んだもののETS名前空間は、「政府の緊急通信サービス」（またはGETS）と呼ばれる米国政府の電気通信サービスの名前から間接的にその名の由来しますこれは「緊急通信サービス」の略です。
The ETS namespace defines the following resource values, listed from lowest priority to highest priority:
ETS名前空間は、最低の優先度から最も高い優先度にリストされた次のリソース値を定義します。
(lowest) ets.4 ets.3 ets.2 ets.1 (highest) ets.0
（最低）ets.4 ets.3 ets.2 ets.1（最高）ets.0
The ETS namespace operates according to the priority queueing algorithm (Section 4.5.2).
ETS名前空間には、プライオリティキューイングアルゴリズム（4.5.2）に従って動作します。
The WPS namespace derives its name from the "Wireless Priority Service", defined in GSM and other wireless technologies.
WPS名前空間には、GSMおよび他の無線技術で定義された「ワイヤレス優先サービス」からその名の由来します。
The WPS namespace defines the following resource values, listed from lowest priority to highest priority:
WPS名前空間は、最低の優先度から最も高い優先度にリストされた次のリソース値を定義します。
(lowest) wps.4 wps.3 wps.2 wps.1 (highest) wps.0
（最低）wps.4 wps.3 wps.2 wps.1（最高）wps.0
The WPS namespace operates according to the priority queueing algorithm (Section 4.5.2).
WPS名前空間には、プライオリティキューイングアルゴリズム（4.5.2）に従って動作します。
Any resource priority mechanism can be abused to obtain resources and thus deny service to other users. An adversary may be able to take over a particular PSTN gateway, cause additional congestion during emergencies affecting the PSTN, or deny service to legitimate users. In SIP end systems, such as IP phones, this mechanism could inappropriately terminate existing sessions and calls.
任意のリソース優先順位メカニズムは、リソースを得るため、他のユーザーへのサービスを拒否するために悪用されることができます。敵は、特定のPSTNゲートウェイを引き継ぐPSTNに影響を与える緊急時に追加の混雑を引き起こし、または正当なユーザーへのサービスを拒否することができるかもしれません。 IP電話などのSIPエンドシステムでは、このメカニズムは不適切既存のセッションとの通話を終了することができます。
Thus, while the indication itself does not have to provide separate authentication, SIP requests containing this header are very likely to have higher authentication requirements than those without.
表示自体は別個の認証を提供する必要はないしつつ、このヘッダを含むSIP要求がないものよりも高い認証要件を有する可能性が非常に高いです。
These authentication and authorization requirements extend to users within the administrative domain, as later interconnection with other administrative domains may invalidate earlier assumptions on the trustworthiness of users.
他の管理ドメインと後で相互接続は、ユーザーの信頼性に以前の仮定を無効にするように、これらの認証と認可の要件は、管理ドメイン内のユーザに及びます。
Below, we describe authentication and authorization aspects, confidentiality and privacy requirements, protection against denial-of-service attacks, and anonymity requirements. Naturally, the general discussion in RFC 3261 [RFC3261] applies.
以下に、私たちは、機密性とプライバシー要件、サービス拒否攻撃に対する保護、および匿名性の要件、認証と認可の側面を記述する。当然のことながら、RFC 3261における一般的な議論は[RFC3261]は適用されます。
All user agents and proxy servers that support this extension MUST implement SIP over TLS [RFC3546], the 'sips' URI scheme as described in Section 26.2 of RFC 3261, and Digest Authentication [RFC2617] as described in Section 22 of RFC 3261. In addition, user agents that support this extension SHOULD also implement S/MIME [RFC3851] as described in Section 23 of RFC 3261 to allow for signing and verification of signatures over requests that use this extension.
でRFC 3261のセクション22に記載されているようにRFC 3261のセクション26.2、およびダイジェスト認証[RFC2617]に記載されているようにこの拡張をサポートするすべてのユーザエージェントとプロキシサーバは、TLS [RFC3546]の上に「SIPS」URIスキームをSIPを実装しなければなりませんまた、RFC 3261のセクション23に記載されているように、この拡張をサポートするユーザエージェントは、この拡張を使用するリクエストの上の署名の署名および検証を可能にするために、S / MIME [RFC3851]を実装する必要があります。
Prioritized access to network and end-system resources imposes particularly stringent requirements on authentication and authorization mechanisms, since access to prioritized resources may impact overall system stability and performance and not just result in theft of, say, a single phone call.
優先順位のリソースへのアクセスは、システム全体の安定性とパフォーマンスに影響を与え、1つだけの電話、たとえば、の盗難が得られない可能性があるため、ネットワークおよびエンドシステムリソースへの優先順位付けされたアクセスは、認証と承認のメカニズムに特に厳しい要件を課しています。
Under certain emergency conditions, the network infrastructure, including its authentication and authorization mechanism, may be under attack.
特定の緊急条件の下では、その認証および承認機構を備えたネットワークインフラストラクチャは、攻撃の下にあってもよいです。
Given the urgency during emergency events, normal statistical fraud detection may be less effective, thus placing a premium on reliable authentication.
緊急事態時の緊急性を考えると、通常の統計的な不正検出は、このように信頼性の高い認証にプレミアムを配置し、あまり効果的です。
Common requirements for authentication mechanisms apply, such as resistance to replay, cut-and-paste, and bid-down attacks.
認証メカニズムのための一般的な要件は、このような、リプレイカットアンドペースト、および入札ダウン攻撃への抵抗として、適用されます。
Authentication MAY be SIP based or use other mechanisms. Use of Digest authentication and/or S/MIME is RECOMMENDED for UAS authentication. Digest authentication requires that the parties share a common secret, thus limiting its use across administrative domains. SIP systems employing resource priority SHOULD implement S/MIME at least for integrity, as described in Section 23 of [RFC3261]. However, in some environments, receipt of asserted identity [RFC3325] from a trusted entity may be sufficient authorization. Section 5 describes third-party authentication.
認証は、SIPベースであるか、または他のメカニズムを使用するかもしれません。ダイジェスト認証および/またはS / MIMEの使用はUAS認証をお勧めします。ダイジェスト認証は、このような管理ドメイン間でその使用を制限し、当事者が共通の秘密を共有することが必要です。 [RFC3261]のセクション23に記載されているようにリソース優先順位を採用SIPシステムは、少なくとも完全性のためにS / MIMEを実装する必要があります。ただし、一部の環境では、信頼できるエンティティからのアサートされたアイデンティティ[RFC3325]の領収書が必要な許可かもしれません。第5節では、サードパーティの認証について説明します。
Trait-based authorization [TRAIT] "entails an assertion by a authorization service of attributes associated with an identity" and may be appropriate for this application. With trait-based authorization, a network element can directly determine, by inspecting the certificate, that a request is authorized to obtain a particular type of service, without having to consult a mapping mechanism that converts user identities to authorizations.
形質ベースの許可[形質は、「アイデンティティに関連付けられた属性の認可サービスによってアサーションを伴う」、このアプリケーションのために適切であり得ます。形質ベースの認証と、ネットワーク要素が直接要求を承認するユーザーIDを変換するマッピング機構に相談することなく、サービスの特定の種類を取得することを許可されていることを、証明書を検査することによって、決定することができます。
Authorization may be based on factors besides the identity of the caller, such as the requested destination. Namespaces MAY also impose particular authentication or authorization considerations that are stricter than the baseline described here.
認可は、要求された宛先として発信者のアイデンティティ以外の要因に基づくことができます。名前空間はまた、ここで説明したベースラインよりも厳しい特定の認証または許可の配慮を課すことができます。
Calls that use elevated resource priority levels provided by the 'Resource-Priority' header field are likely to be sensitive and often need to be protected from intercept and alteration. In particular, requirements for protecting the confidentiality of communications relationships may be higher than those for normal commercial service. For SIP, the 'To', 'From', 'Organization', and 'Subject' header fields are examples of particularly sensitive information. Systems MUST implement encryption at the transport level using TLS and MAY implement other transport-layer or network-layer security mechanisms. UACs SHOULD use the "sips" URI to request a secure transport association to the destination.
「リソース優先」ヘッダフィールドが提供する高いリソースの優先順位を使用するコールは敏感である可能性が高いと、多くの場合、インターセプトと改ざんから保護する必要があります。具体的には、通信関係の機密性を保護するための要件は、通常の商用サービスのためのものよりも高くてもよいです。 SIPは、「に」、「組織」「」から、および「件名」ヘッダフィールドは、特に機密情報の一例です。システムは、TLSを使用して、トランスポート・レベルで暗号化を実装しなければならないし、他のトランスポート層またはネットワーク層セキュリティメカニズムを実装することができます。求めるUACは、目的地への安全な輸送関連付けを要求するために「一口」URIを使用すべきです。
The 'Resource-Priority' header field can be carried in the SIP message header or can be encapsulated in a message fragment carried in the SIP message body [RFC3420]. To be considered valid authentication for the purposes of this specification, S/MIME-signed
「リソースプライオリティ」ヘッダフィールドは、SIPメッセージヘッダで搬送することができ、またはSIPメッセージボディ[RFC3420]で運ばメッセージフラグメントにカプセル化することができます。本明細書の目的のために有効な認証と見なされるためには、S / MIME署名
SIP messages or fragments MUST contain, at a minimum, the Date, To, From, Call-ID, and Resource-Priority header fields. Encapsulation in S/MIME body parts allows the user to protect this header field against inspection or modification by proxies. However, in many cases, proxies will need to authenticate and authorize the request, so encapsulation would be undesirable.
SIPメッセージまたはフラグメントは、最低でも、日付は、から、に、-IDを呼び出し、およびリソース優先ヘッダフィールド、含まれていなければなりません。 S / MIMEボディ部分にカプセル化は、ユーザがプロキシによって検査又は修正に対するこのヘッダフィールドを保護することを可能にします。しかし、多くの場合、プロキシは要求を認証し、認可する必要がありますので、カプセル化は望ましくないであろう。
Removal of a Resource-Priority header field or downgrading its priority value affords no additional opportunities to an adversary, since that man-in-the-middle could simply drop or otherwise invalidate the SIP request and thus prevent call completion.
リソース優先ヘッダフィールドの除去またはそれのman-in-the-middleは単にドロップまたは他のSIP要求を無効にし、従って呼完了を妨げる可能性があるので、その優先度の値は、敵対者に追加の機会を提供しないダウングレード。
Only SIP elements within the same administrative trust domain employing a secure channel between their SIP elements will trust a Resource-Priority header field that is not appropriately signed. Others will need to authenticate the request independently. Thus, insertion of a Resource-Priority header field or upgrading the priority value has no further security implications except causing a request to fail (see discussion in the previous paragraph).
彼らのSIP要素間のセキュアチャネルを使用する同一の管理信頼ドメイン内のSIP要素のみを適切に署名されていないリソースプライオリティヘッダーフィールドを信頼します。その他には、独立して、要求を認証する必要があります。したがって、リソースプライオリティヘッダーフィールドまたは優先順位値をアップグレードの挿入が失敗する（前の段落で考察を参照）要求を発生させる以外に、さらに、セキュリティ意味を持ちません。
Some users may wish to remain anonymous to the request destination. Anonymity for requests with resource priority is no different from that for any other authenticated SIP request. For the reasons noted earlier, users have to authenticate themselves towards the SIP elements carrying the request where they desire resource priority treatment. The authentication may be based on capabilities and noms, not necessarily their civil name. Clearly, they may remain anonymous towards the request destination, using the network-asserted identity and general privacy mechanism described in [RFC3323].
一部のユーザーは、要求先に匿名を希望することがあります。リソース優先順位の要求のための匿名性は、他の認証されたSIPリクエストのためのものと変わりません。先に述べた理由から、ユーザーは、リソースの優先処理を望む要求を運ぶSIP要素に向けて自分自身を認証する必要があります。認証は、彼らの市民名前必ずしも、機能とNOMSに基づくことができます。明らかに、彼らはネットワークアサートアイデンティティおよび[RFC3323]に記載されている一般的なプライバシーのメカニズムを使用して、依頼先への匿名のままです。
As noted, systems described here are likely to be subject to deliberate denial-of-service (DoS) attacks during certain types of emergencies. DoS attacks may be launched on the network itself as well as on its authentication and authorization mechanism. As noted, systems should minimize the amount of state, computation, and network resources that an unauthorized user can command. The system must not amplify attacks by causing the transmission of more than one packet to a network address whose reachability has not been verified.
述べたように、ここで説明されるシステムは、緊急事態の特定の種類の中にサービス拒否（DoS）攻撃を審議の対象である可能性があります。 DoS攻撃は、ネットワーク自体にだけでなく、その認証および承認メカニズムに開始することができます。述べたように、システムは、不正なユーザが命令することができる状態、計算、およびネットワークリソースの量を最小化すべきです。システムは、その到達可能性検証されていないネットワークアドレスに複数のパケットの送信を引き起こすことによって、攻撃を増幅してはいけません。
This section defines two new SIP headers (Section 12.2), one SIP option tag (Section 12.3), one new 4xx error code (Section 12.4), a new registry within the sip-parameters section of IANA for Resource-Priority namespaces (Section 12.5), and a new registry within the sip-parameters section of IANA for Resource-Priority and priority-values (Section 12.6).
このセクションでは、リソース優先名前空間のためのIANAのSIP-パラメータセクション（セクション12.5内の2つの新しいSIPヘッダ（セクション12.2）、1つのSIPオプションタグ（セクション12.3）、一つの新たな4XXエラーコード（セクション12.4）、新しいレジストリを定義します）、およびリソース・優先度と優先順位値（12.6）のためのIANAのSIP-パラメータセクション内の新しいレジストリ。
Additional namespaces and priority values MUST be registered with IANA, as described in Section 9.
セクション9に記載されているように、追加の名前空間と優先順位値は、IANAに登録されなければなりません。
The SIP Change Process [RFC3427] establishes a policy for the registration of new SIP extension headers. Resource priority namespaces and priority values have similar interoperability requirements to those of SIP extension headers. Consequently, registration of new resource priority namespaces and priority values requires documentation in an RFC using the extension header approval process specified in RFC 3427.
SIP変更処理[RFC3427]は、新たなSIPの拡張ヘッダの登録のためのポリシーを確立します。リソース優先名前空間と優先度の値は、SIPの拡張ヘッダと同様の相互運用性の要件があります。結果として、新しいリソース優先名前空間と優先順位値の登録は、RFC 3427で指定された拡張ヘッダの承認プロセスを使用して、RFCのドキュメントを必要とします。
Registration policies for new namespaces are defined in Section 9.
新しい名前空間の登録ポリシーは、セクション9で定義されています。
12.2. IANA Registration of 'Resource-Priority' and 'Accept-Resource-Priority' Header Fields
12.2. 「リソース優先」と「受け入れ資源-優先」ヘッダフィールドのIANA登録
The following is the registration for the 'Resource-Priority' header field:
以下は、「資源の優先順位」ヘッダフィールドの登録です。
RFC number: 4412 Header name: 'Resource-Priority' Compact form: none
RFC番号：4412ヘッダー名：「リソース優先」コンパクト形：なし
The following is the registration for the 'Accept-Resource-Priority' header field:
以下は、「受け入れ資源を優先」ヘッダフィールドの登録です。
RFC number: 4412 Header name: Accept-Resource-Priority Compact form: none
RFC番号：4412ヘッダー名：受け入れ資源優先コンパクト形：なし
RFC number: 4412 Name of option tag: 'resource-priority' Descriptive text: Indicates or requests support for the resource priority mechanism.
RFC番号：オプションタグの4412名：「リソースの優先度」説明文：指定したり、リソースの優先順位メカニズムのサポートを要求します。
RFC number: 4412 Response code: 417 Default reason phrase: Unknown Resource-Priority
RFC番号：4412応答コード：417デフォルトの理由フレーズ：不明なリソース優先
A new registry ("Resource-Priority Namespaces") in the sip-parameters section of IANA has been created, taking a form similar to this table below:
IANAのSIPパラメータセクションに新しいレジストリ（「リソースプライオリティネームスペース」）は、以下のこのテーブルに似た形を取って、作成されています：
Intended New warn- New resp.
Namespace Levels Algorithm code code Reference
--------- ------ ---------------- --------- --------- ---------
dsn 5 preemption no no [RFC4412]
drsn 6 preemption no no [RFC4412]
DRSN 6プリエンプション不可NO [RFC4412]
q735 5 preemption no no [RFC4412]
q735 5プリエンプション不可NO [RFC4412]
ets 5 queue no no [RFC4412]
5は一切キューません[RFC4412]
wps 5 queue no no [RFC4412]
WPS 5キューなしなし[RFC4412]
Legend
------
Namespace The unique string identifying the namespace.
Levels The number of priority-values within the namespace.
Algorithm Intended operational behavior of SIP elements
implementing this namespace.
New Warn code New Warning Codes (warn-codes) introduced by
this namespace.
New Resp. code New SIP response codes introduced by this namespace.
Reference IETF document reference for this namespace.
A new registry ("Resource-Priority Priority-values") in the sip-parameters section of IANA has been created, taking a form similar to this table below:
IANAのSIPパラメータセクションに新しいレジストリ（「リソース・優先順位優先順位値」）は、以下のこのテーブルに似た形を取って、作成されています：
Namespace: drsn Reference: RFC 4412 Priority-Values (least to greatest): "routine", "priority", "immediate", "flash", "flash-override", "flash-override-override"
名前空間：DRSN参考：RFC 4412優先順位値（最大と最小）：「ルーチン」、「優先度」、「即時」、「フラッシュ」、「フラッシュ・オーバーライド」、「フラッシュオーバーライドオーバーライド」
Namespace: dsn Reference: RFC 4412 Priority-Values (least to greatest): "routine", "priority", "immediate", "flash", "flash-override"
名前空間：DSN参考：RFC 4412優先順位値（最大と最小）：「ルーチン」、「優先度」、「即時」、「フラッシュ」、「フラッシュ・オーバーライド」
Namespace: q735 Reference: RFC 4412 Priority values (least to greatest): "4", "3", "2", "1", "0"
名前空間：q735リファレンス：RFC 4412の優先値（少なくとも最大に）： "4"、 "3"、 "2"、 "1"、 "0"
Namespace: ets Reference: RFC 4412 Priority values (least to greatest): "4", "3", "2", "1", "0"
名前空間：ETS参照：RFC 4412の優先値（少なくとも最大に）： "4"、 "3"、 "2"、 "1"、 "0"
Namespace: wps Reference: RFC 4412 Priority values (least to greatest): "4", "3", "2", "1", "0"
名前空間：WPS参照：RFC 4412の優先値（少なくとも最大に）： "4"、 "3"、 "2"、 "1"、 "0"
Ben Campbell, Ken Carlberg, Paul Kyzivat, Rohan Mahy, Allison Mankin, Xavier Marjou, Piers O'Hanlon, Mike Pierce, Samir Srivastava, and Dale Worley provided helpful comments.
ベン・キャンベル、ケン・カールバーグ、ポールKyzivat、ロハンマーイ、アリソンマンキン、ザビエルMarjou、埠頭オハンロン、マイク・ピアース、サミールSrivastava氏、そしてデールウォーリーは役に立つコメントを提供しました。
Dean Willis provided much help with this effort.
ディーン・ウィリスは、この労力で多くの助けを提供しました。
Martin Dolly, An Nguyen, and Niranjan Sandesara assisted with the ETS and WPS namespaces.
マーティン・ドリー、アングエン、およびNiranjan SandesaraはETSとWPSの名前空間を支援します。
Janet Gunn helped improve the text on queueing-based priority.
ジャネット・ガンは、キューイングベースの優先順位上のテキストを改善する助けました。
[I.255.3] International Telecommunications Union, "Integrated Services Digital Network (ISDN) - General Structure and Service Capabilities - Multi-Level Precedence and Preemption", Recommendation I.255.3, July 1990.
[I.255.3]国際電気通信連合、「総合デジタル通信網（ISDN） - 一般的な構造とサービス機能 - マルチレベル優先順位および優先処理」、勧告I.255.3、1990年7月。
[Q.735.3] International Telecommunications Union, "Stage 3 description for community of interest supplementary services using Signalling System No. 7: Multi-level precedence and preemption", Recommendation Q.735.3, March 1993.
[Q.735.3]国際電気通信連合、「シグナリングシステム番号7使って関心付加サービスのコミュニティのためのステージ3の説明：マルチレベルの優先順位とプリエンプション」、勧告Q.735.3、1993年3月を。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 2434、1998年10月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002.
[RFC3262]ローゼンバーグ、J.、およびH. Schulzrinneと、RFC 3262、2002年6月 "セッション開始プロトコル（SIP）における暫定的な応答の信頼性"。
[RFC3265] Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[RFC3265]ローチ、A.B.、 "セッション開始プロトコル（SIP）特異的イベント通知"、RFC 3265、2002年6月。
[RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002.
[RFC3311]ローゼンバーグ、J.、 "セッション開始プロトコル（SIP）更新方法"、RFC 3311、2002年10月。
[RFC3420] Sparks, R., "Internet Media Type message/sipfrag", RFC 3420, November 2002.
[RFC3420]スパークス、R.、 "インターネットメディアタイプのメッセージ/ sipfrag"、RFC 3420、2002年11月。
[RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002.
[RFC3428]キャンベル、B.、ローゼンバーグ、J.、Schulzrinneと、H.、のHuitema、C.、およびD. Gurle、 "インスタントメッセージングのためのセッション開始プロトコル（SIP）拡張子"、RFC 3428、2002年12月。
[RFC4411] Polk, J., "Extending the Session Initiation Protocol (SIP) Reason Header for Preemption Events", RFC 4411, February 2006.
[RFC4411]ポーク、J.、 "プリエンプションのイベントのためのセッション開始プロトコル（SIP）Reasonヘッダの拡張"、RFC 4411、2006年2月。
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999.
[RFC2617]フランクス、J.、ハラム・ベイカー、P.、Hostetler、J.、ローレンス、S.、リーチ、P.、Luotonen、A.、およびL.スチュワート、 "HTTP認証：基本とダイジェストアクセス認証" 、RFC 2617、1999年6月。
[RFC2976] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.
[RFC2976]ドノバン、S.、 "SIP INFOメソッド"、RFC 2976、2000年10月。
[RFC3323] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002.
[RFC3323]ピーターソン、J.、RFC 3323、2002年11月 "セッション開始プロトコル（SIP）のためのプライバシーメカニズム"。
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002.
[RFC3325]ジェニングス、C.、ピーターソン、J.、およびM.ワトソン、 "信頼できるネットワーク内のアサート・アイデンティティのためのセッション開始プロトコル（SIP）のプライベート拡張"、RFC 3325、2002年11月。
[RFC3427] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J., and B. Rosen, "Change Process for the Session Initiation Protocol (SIP)", BCP 67, RFC 3427, December 2002.
[RFC3427]マンキン、A.、ブラドナー、S.、マーイ、R.、ウィリス、D.、オット、J.、およびB.ローゼン、 "セッション開始プロトコル（SIP）のための変更処理"、BCP 67、RFC 3427、2002年12月。
[RFC3487] Schulzrinne, H., "Requirements for Resource Priority Mechanisms for the Session Initiation Protocol (SIP)", RFC 3487, February 2003.
[RFC3487] Schulzrinneと、H.、RFC 3487 "セッション開始プロトコル（SIP）のためのリソースプライオリティメカニズムのための要件"、2003年2月。
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[RFC3515]スパークス、R.、 "セッション開始プロトコル（SIP）メソッドを参照してください"、RFC 3515、2003年4月。
[RFC3546] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 3546, June 2003.
[RFC3546]ブレイク・ウィルソン、S.、Nystrom、M.、ホップウッド、D.、ミケルセン、J.、およびT.ライト、 "トランスポート層セキュリティ（TLS）の拡張"、RFC 3546、2003年6月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550] Schulzrinneと、H.、Casner、S.、フレデリック、R.、およびV.ヤコブソン、 "RTP：リアルタイムアプリケーションのためのトランスポートプロトコル"、STD 64、RFC 3550、2003年7月。
[RFC3665] Johnston, A., Donovan, S., Sparks, R., Cunningham, C., and K. Summers, "Session Initiation Protocol (SIP) Basic Call Flow Examples", BCP 75, RFC 3665, December 2003.
[RFC3665]ジョンストン、A.、ドノバン、S.、スパークス、R.、カニンガム、C.、およびK.サマーズ、 "セッション開始プロトコル（SIP）の基本的なコールフローの例"、BCP 75、RFC 3665、2003年12月。
[RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[RFC3851] Ramsdell、B.、 "/セキュア多目的インターネットメール拡張（S / MIME）バージョン3.1メッセージ仕様"、RFC 3851、2004年7月。
[RFC3893] Peterson, J., "Session Initiation Protocol (SIP) Authenticated Identity Body (AIB) Format", RFC 3893, September 2004.
[RFC3893]ピーターソン、J.、 "セッション開始プロトコル（SIP）認証済みアイデンティティボディ（AIB）フォーマット"、RFC 3893、2004年9月。
[RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension for Event State Publication", RFC 3903, October 2004. for Event State Publication", RFC 3903, October 2004.
[RFC3903]ニエミ、A.、「イベント状態の出版のためのRFC 3903、2004年10月、RFC 3903 "イベントステート発行のためのセッション開始プロトコル（SIP）の拡張"、2004年10月。
[TRAIT] Peterson, J., Polk, J., Sicker, D., and H. Tschofenig, "Trait-based Authorization Requirements for the Session Initiation Protocol (SIP)", Work in Progress, February 2005.
[形質]ピーターソン、J.、ポーク、J.、病状、D.、およびH. Tschofenig、進歩、2005年2月ワーク "セッション開始プロトコル（SIP）のための形質ベースの承認要件"。
Authors' Addresses
著者のアドレス
Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 US
コンピュータサイエンス450コンピュータサイエンスビル、ニューヨーク、NY 10027米国のヘニングSchulzrinneとコロンビア大学学部
Phone: +1 212 939 7004 EMail: hgs@cs.columbia.edu URI: http://www.cs.columbia.edu
電話：+1 212 939 7004 Eメール：hgs@cs.columbia.edu URI：http://www.cs.columbia.edu
James Polk Cisco Systems 2200 East President George Bush Turnpike Richardson, TX 75082 US
ジェームズ・ポークシスコシステムズ2200東ブッシュ大統領ターンパイクリチャードソン、TX 75082米国
EMail: jmpolk@cisco.com
メールアドレス：jmpolk@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY 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 provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。