[要約] RFC 4412は、SIPにおける通信リソースの優先度を定義するものであり、要約すると以下のようになります。1. SIPセッションにおける通信リソースの優先度を設定するための仕様。 2. ネットワーク上のリソース制約や品質要件に基づいて、SIPメッセージに優先度を付与する方法を提供。 3. リアルタイム通信やエマージェンシーコミュニケーションなど、特定のセッションに優先的なリソース割り当てを可能にすることを目的とする。
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)
セッション開始プロトコル（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).
Copyright（c）The Internet Society（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.
このドキュメントでは、リソースの優先順位を通知するための2つの新しいセッション開始プロトコル（SIP）ヘッダーフィールドを定義します。「リソース優先度」ヘッダーフィールドは、SIPユーザーエージェント（電話ゲートウェイやIP電話など）および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ベースのサービスがあります。このメモは、セッション開始プロトコル（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ゲートウェイは、PublicのSIPゲートウェイによって発信されたISUP（ISDNユーザーパーツ）IAM（ISDNユーザーパーツ）IAM（ISDNユーザーパーツ）の優先度を示す発信コールをマークする可能性があります。切り替えた電話ネットワーク（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.
このドキュメントでは、「リソース優先度」と「受け入れリソースの優先度」と呼ばれる通信リソースの優先度のための2つの新しいSIPヘッダーフィールド（セクション3）を定義します。「リソース優先度」ヘッダーフィールドは、PSTNコールの優先順位を含むSIPリクエストの処理に影響を与えるために、パブリックスイッチド電話ネットワーク（PSTN）ゲートウェイや端末を含むSIPユーザーエージェントによって使用できます。PSTNゲートウェイの場合、動作はPSTNの類似のスキームに変換されます。たとえば、PSTNからIPへの両方の方向の両方で、ITU推奨Q.735.3 [Q.735.3]優先順位付けメカニズム。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.
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.
4. SIPプロキシおよび連続したユーザーエージェントでは、より高い優先順位の要求が既存のシグナリング要求を置き換えるか、優先順位の低下に対して有効な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に従います。この仕様またはサポートされている拡張機能で）では、サーバーはそのヘッダーフィールドを無視し、メッセージの処理を継続する必要があります。したがって、このメカニズムの使用は、リクエストにリソース優先オプションタグを備えた要求ヘッダーフィールドが含まれていない限り、既存の実装には完全に見えません。
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]の要件を満たすことを目的としています。[RFC3487]で定義されているすべてのSIPおよびリアルタイムトランスポートプロトコル（RTP）[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アクターとして機能するSIPプロキシとユーザーエージェント（UAS）を参照します。
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クライアントを変更せずに、これらのネットワークのいくつかで許可された優先度処理を取得できるようにしたいと考えています。また、1回の呼び出しでは、さまざまな管理によって実行され、異なる優先メカニズムの対象となるSIP要素を横断する場合があります。これらの優先順位の間にグローバルな注文はないため、各リクエストは、このドキュメントの名前空間と呼ばれるこれらの異なる優先順位リストから描かれた複数の優先順位値を含めることを許可します。通常、各SIP要素はそのような名前空間の1つのみをサポートしますが、セクション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の2つの新しいSIPヘッダーフィールドの構文を定義し、セクション4のプロトコルの動作について説明します。セクション4.5。エラー条件は、セクション4.6でカバーされています。セクション4.7.1〜4.7.3特定のSIP要素の動作を詳しく説明しています。サードパーティの認証はセクション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.
プロトコルの例については、セクション7で説明します。セクション8では、要求に複数の名前空間が含まれている場合、または要素が複数の名前空間を処理できる場合に何が起こるかについて説明します。セクション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.
このドキュメントでは、キーワードが「必須」、「必須」、「必須」、「shall」、「shall "、" low "of" bould "、" becommented "、"、 "、"、 "optional"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].
「リソース優先度」ヘッダーフィールドの構文を以下に説明します。「トークンノドット」の生産は[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 / "-" / "!" / "%" / "*"
/ "_" / "+" / "`" / "'" / "~" )
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」は同等です。各名前空間には、少なくとも1つの優先順位値があります。各名前空間内の名前空間と優先度の値は、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値」の順序は重要ではありません。したがって、たとえば、次の3つのヘッダースニペットは同等です。
Resource-Priority: dsn.flash, wps.3
リソース優先度：DSN.FLASH、WPS.3
Resource-Priority: wps.3, dsn.flash Resource-Priority: wps.3 Resource-Priority: dsn.flash
リソース優先度：WPS.3、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)]
Accept-Resource-Priority = "Accept-Resource-Priority" hcolon [r-value *（comma r-value）]]
An example is given below:
例を以下に示します。
Accept-Resource-Priority: dsn.flash-override, dsn.flash, dsn.immediate, dsn.priority, dsn.routine
Accept-Resource-Priority：dsn.flash-override、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.
一部の管理ドメインでは、応答におけるそのドメインに関する情報が多すぎるために、「受け入れリソースの優先度」ヘッダーの使用を無効にすることを選択する場合があります。ただし、このヘッダーフィールドはトラブルシューティングに役立つため、この動作は推奨されません。
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]、購読（subとラベル付け）および[RFC3265]でメソッドを通知（ラベル付け）、[RFC3311]のアップデート（UPD）メソッド、メッセージ（MSG）で定義されています。[RFC3428]の方法[RFC3515]の参照（REF）メソッド、[RFC2976]の情報（INF）メソッド、および[RFC3903]のパブリッシュ（PUB）メソッド。
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.
他の要求方法は、独自の処理ルールを定義する場合があります。特に指定されていない限り、受信者はこれらのヘッダーフィールドを無視する場合があります。
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.
この仕様をサポートするすべてのSIPユーザーエージェントとプロキシサーバーは、特定の共通の動作を共有します。これについては、以下でセクション4.2で説明します。「リソース優先度」オプションタグが「要求」ヘッダーフィールドで発生した場合の動作については、セクション4.3で説明します。セクション4.4では、オプションリクエストの処理について説明します。2つの基本的なリソース競合解像度の解決メカニズム、先制とキューイングは、セクション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]
o ACK [RFC3261]
o ACK [RFC3261]
o PRACK [RFC3262]
o プラック[RFC3262]
o UPDATE [RFC3311]
o 更新[RFC3311]
o REFER [RFC3515]
o [RFC3515]を参照してください
Implementations SHOULD support the 'Resource-Priority' header field in the following request types:
実装は、次の要求タイプで「リソース優先度」ヘッダーフィールドをサポートする必要があります。
o MESSAGE [RFC3428]
o メッセージ[RFC3428]
o SUBSCRIBE [RFC3265]
o 購読[RFC3265]
o NOTIFY [RFC3265] Note that this does not imply that all implementations have to support all request methods listed.
o 通知[RFC3265]これは、すべての実装がリストされているすべての要求方法をサポートする必要があることを意味しないことに注意してください。
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].
[RFC3261]のルールに従って、SIP要素が上記のもの以外の要求以外のリクエストで「リソース優先度」ヘッダーフィールドを受信した場合、ヘッダーは無視される場合があります。
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.
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.
オプション要求を使用して、要素がメカニズムをサポートするかどうかを判断できます。準拠した実装では、すべての有効なリソース値を列挙するオプション応答の「受け入れリソース優先」ヘッダーフィールドを返す必要がありますが、RPアクターは、そのような値を返さないように構成されているか、それらを認可された要求者に返すように設定される場合があります。
Following standard SIP behavior, OPTIONS responses MUST include the 'Supported' header field that includes the 'resource-priority' option tag.
標準のSIP動作に続いて、オプションの応答には、「リソース優先度」オプションタグを含む「サポートされている」ヘッダーフィールドを含める必要があります。
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がプロキシサーバーとユーザーエージェントサーバーの両方の機能を発見できるようにします。
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.
当然のことながら、このメカニズムと名前空間とリソース値を理解する要素のみがこれらのアルゴリズムを実行します。セクション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.
このセクションでは、複数のタイプのRPアクター（トランクゲートウェイ、ラインゲートウェイ、IP電話などのUASのさまざまなインスタンスを含む）とプロキシと共有されるエラー動作について説明します。
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
o 認証された要求者は、そのようなリクエスト（セクション4.6.4）を行うことを許可されていません。
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.
これらのエラーケースは、リソース優先ヘッダーを使用してリクエストの処理で通常発生する順に扱います。ただし、この注文は義務付けられていません。たとえば、特定のリソース値を提供できないことやキューに留められていない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.
ケースを作成する（1）デフォルトは必要です。そうしないと、UASに途中でプロキシがUACと共通の名前空間を共有しない場合にコールを正常に完了する方法がないため、UACとUASはそのようなものを持っています。共通の名前空間。
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（不明なリソース優先度）応答には、ローカルポリシーによると、許容可能なリソース値を列挙する「受け入れリソース優先性」ヘッダーフィールドが含まれる場合があります。
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（ここでビジー）応答を返します。
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 UACSは、リソースアクセスの優先順位を高める必要があるリクエストに対して、「リソース優先度」ヘッダーフィールドを生成できる必要があります。前述のように、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は同じまたは異なるリソース値で後続の要求を試みることができます。利用可能な場合は、「受け入れリソースの優先度」ヘッダーフィールドで返された値のセットから認定されたリソース値を選択する必要があります。
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].
先制を引き起こす可能性のある優先値を要求するUACは、[RFC4411]で説明されているように、セッションが終了した理由を説明するBYEリクエストの理由ヘッダーフィールドを理解する必要があります。
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つを交換する必要があります。デバイスに予備のセッションがある場合、実装は、より優先順位のコールの到着をCalleeに警告することを選択できます。詳細は、ローカルまたは名前空間ポリシーで設定することもできます。
[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メッセージに理由ヘッダーを含めることにより、セッションの意図的または管理上の終了の場合に追加情報を提供します。そのドキュメントのメカニズムにより、終了が発生した場所（「UAで」、「予約内」、「IP/PSTNゲートウェイで」）を示すことができ、各理由のコールフロー例を含めます。
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プロキシは、「リソース優先度」ヘッダーフィールドを無視する場合があります。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].
RFC 3261のセクション23に従ってS/MIMEカプセル化が使用されている場合、特別な考慮事項が適用されます。セクション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アクターが要求者のIDを決定するのに役立ちます。
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.
このドキュメントで説明されているリソース優先メカニズムは、[RFC3261]に続くSIPシステムと完全に逆方向に互換性があります。メカニズムを理解していないシステムは、上昇していない標準的なサービスの優先順位のみを提供できます。ユーザーエージェントサーバーとプロキシは、他の不明なヘッダーフィールドと同じように「リソース優先度」ヘッダーフィールドを無視し、他のリクエストと同じようにリクエストを扱うことができます。当然、リクエストはまだ成功する可能性があります。
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ユーザーを招待する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: ...
...
...
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
F3 200 OK User B -> User 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: ...
...
...
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（不明なリソース優先度）ステータスコードを返します。メッセージF5からF7のメッセージの詳細は省略します。これは、最初の例と本質的に同じであるためです。
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ユーザーを招待する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>
Content-Type: application/sdp
Content-Length: ...
...
...
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
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
F4 INVITE User A -> User 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>
Content-Type: application/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アクターが処理の残りのリソース値の1つを選択し、通常、相対的な優先度が最も高いリソース値を選択する場合にのみ対応します。
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).
以下は、FooとBarの2つの名前空間をサポートするRPアクターの例のセットです。Fooの優先順位値は3（最高）、次に2、次に1（最低）であり、Barの優先順位値はC（最高）、B、A（最低）です。
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)
foo.3 foo.3 bar.c（最優先事項）foo.2 bar.c foo.3 foo.1またはfoo.2 bar.c bar.b foo.1 bar.b foo.1 bar。b bar.a bar.a bar.a（最優先事項）
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).
o 優先アルゴリズム（セクション4.5）。名前空間を優先キューイング（「キュー」）またはプリエンプション（「プリエンプション」）で使用するかどうかを識別します。キューイングを使用すると、名前空間は通常の優先度要求がキューに登録されているかどうかを示す場合があります。すべての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.
o 名前空間は、優先度値の既存のリストを参照するか、SIPパラメータリソース優先度の優先順位-valuesレジストリ内でIANA登録の相対的な優先順位順序で優先値の新しい有限リストを定義することができます。特定の名前空間に関連付けられた以前の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.
この仕様は、以下の5つの一意の名前空間を定義します：DSN、DRSN、Q735、ETS、およびWPSは、IANAとの登録を構成します。各IANA登録には、セクション9で定義されているファセットが含まれています。認識可能性のために、名前空間に大文字のラベルを付けますが、名前空間名はケースの鈍感であり、プロトコル要求の小文字として慣習的にレンダリングされることに注意してください。
The DSN namespace comes from the name of a US government network called "The Defense Switched Network".
DSNネームスペースは、「The Defense Switched Network」と呼ばれる米国政府ネットワークの名前に由来しています。
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-override
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ネームスペースは、「The Defense Red Switched Network」と呼ばれる米国政府ネットワークの名前に由来しています。
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-override（最高）drsn.flash-override-override
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つのアルゴリズムの側面が異なります。「フラッシュオーバーライドオーバーライド」の優先値の動作は、他の値とは異なります。通常、リクエストは同等の優先度のあるリクエストを先取りしませんが、リソースが不十分な場合、新しく到着する「フラッシュオーバーライドオーバーライド」リクエストは、同等の優先度の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".
ETSの名前空間は、「政府の緊急通信サービス」（または取得）と呼ばれる米国政府の通信サービスの名前から間接的にその名前を導き出しますが、GetSサービスの責任のある組織は、GetS Over IPサービスの頭字語「ETS」を選択しました。「緊急通信サービス」の略です。
The ETS namespace defines the following resource values, listed from lowest priority to highest priority:
ETS NameSpaceは、最低の優先度から最高の優先度にリストされている次のリソース値を定義します。
(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.
この拡張機能をサポートするすべてのユーザーエージェントとプロキシサーバーは、TLS [RFC3546]、RFC 3261のセクション26.2で説明されている「SIPS」URIスキーム、およびRFC 3261のセクション22で説明されているDigest認証[RFC2617]を介して実装する必要があります。さらに、この拡張機能をサポートするユーザーエージェントは、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.
優先順位付けされたリソースへのアクセスは、システム全体の安定性とパフォーマンスに影響を与える可能性があり、たとえば単一の電話の盗難につながる可能性があるため、ネットワークおよびエンドシステムリソースへの優先アクセスは、認証と承認のメカニズムに特に厳しい要件を課します。
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ベースであるか、他のメカニズムを使用する場合があります。Digest認証および/または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.
特性ベースの承認[特性]「アイデンティティに関連付けられた属性の承認サービスによるアサーションを伴う」、このアプリケーションに適切な場合があります。特性ベースの承認により、ネットワーク要素は、証明書を検査することにより、ユーザーのアイデンティティを認証に変換するマッピングメカニズムを参照することなく、特定のタイプのサービスを取得することを要求が許可されていることを直接決定できます。
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の場合、「to」、「from」、 'gonganization、、および' subject 'ヘッダーフィールドは、特に機密情報の例です。システムは、TLSを使用して輸送レベルで暗号化を実装し、他の輸送層またはネットワーク層のセキュリティメカニズムを実装する必要があります。UACは、「SIPS」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 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メッセージヘッダーに携帯するか、SIPメッセージ本文[RFC3420]に掲載されたメッセージフラグメントにカプセル化することができます。この仕様の目的のために有効な認証と見なされるために、S/MIMEシグマのSIPメッセージまたはフラグメントには、少なくとも、日付、Call-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.
リソース優先ヘッダーフィールドを削除したり、優先順位の価値を格下げしたりすると、その中間の男が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要素に対して自分自身を認証する必要があります。認証は、必ずしも彼らの市民名ではなく、能力とノムに基づいている場合があります。明らかに、[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).
このセクションでは、2つの新しいSIPヘッダー（セクション12.2）、1つのSIPオプションタグ（セクション12.3）、1つの新しい4XXエラーコード（セクション12.4）、リソース優先系名物のIANAのSIPパラメータセクション内の新しいレジストリ（セクション12.5の新しいレジストリを定義します。）、およびIANAのSIPパラメータセクション内の新しいレジストリは、リソースの優先順位と優先順位値（セクション12.6）。
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で定義されています。
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ヘッダー名：Accept-Resource-Priority Compactフォーム：なし
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-Parametersセクションに新しいレジストリ（ "Resource-Priority NameSpaces"）が作成され、以下の表に似た形式をとっています。
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プリエンプションいいえ[RFC4412]
ets 5 queue no no [RFC4412]
wps 5 queue no no [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.
ベン・キャンベル、ケン・カールバーグ、ポール・キジバット、ロハン・マヒー、アリソン・マンキン、ザビエル・マルジュー、ピアス・オハンロン、マイク・ピアス、サミール・スリバスタヴァ、デール・ウォーリーは有益なコメントを提供しました。
Dean Willis provided much help with this effort.
ディーン・ウィリスはこの努力に多くの助けを提供しました。
Martin Dolly, An Nguyen, and Niranjan Sandesara assisted with the ETS and WPS namespaces.
NguyenのMartin Dollyと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] International Telecommunications Union、「Integrated Services Digital Network（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] International Telecommunications Union、「シグナリングシステムを使用した関心のあるコミュニティの補足サービスのステージ3説明7：マルチレベルの優先順位と先制」、推奨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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION INTIANIATION Protocol」、RFC 3261、2002年6月。
[RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002.
[RFC3262] Rosenberg、J。およびH. Schulzrinne、「セッション開始プロトコル（SIP）における暫定的な応答の信頼性」、RFC 3262、2002年6月。
[RFC3265] Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[RFC3265] Roach、A.B。、「セッション開始プロトコル（SIP）固有イベント通知」、RFC 3265、2002年6月。
[RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002.
[RFC3311] Rosenberg、J。、「セッション開始プロトコル（SIP）更新方法」、RFC 3311、2002年10月。
[RFC3420] Sparks, R., "Internet Media Type message/sipfrag", RFC 3420, November 2002.
[RFC3420] Sparks、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] Campbell、B.、Rosenberg、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] Polk、J。、「セッション開始プロトコル（SIP）前提条件ヘッダーの拡張」、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] Franks、J.、Hallam-Baker、P.、Hostetler、J.、Lawrence、S.、Leach、P.、Luotonen、A。、およびL. Stewart、「HTTP認証：基本および消化アクセス認証」、RFC 2617、1999年6月。
[RFC2976] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.
[RFC2976] Donovan、S。、「The SIP Info Method」、RFC 2976、2000年10月。
[RFC3323] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002.
[RFC3323]ピーターソン、J。、「セッション開始プロトコル（SIP）のプライバシーメカニズム」、RFC 3323、2002年11月。
[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] Jennings、C.、Peterson、J。、およびM. Watson、「信頼できるネットワーク内の主張されたアイデンティティのセッション開始プロトコル（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] Mankin、A.、Bradner、S.、Mahy、R.、Willis、D.、Ott、J。、およびB. Rosen、「セッション開始プロトコルの変更プロセス（SIP）」、BCP 67、RFC3427、2002年12月。
[RFC3487] Schulzrinne, H., "Requirements for Resource Priority Mechanisms for the Session Initiation Protocol (SIP)", RFC 3487, February 2003.
[RFC3487] Schulzrinne、H。、「セッション開始プロトコル（SIP）のリソース優先メカニズムの要件」、RFC 3487、2003年2月。
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[RFC3515] Sparks、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] Blake-Wilson、S.、Nystrom、M.、Hopwood、D.、Mikkelsen、J。、およびT. Wright、「Transport Layer Security（TLS）Extensions」、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.、Frederick、R。、およびV. Jacobson、「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] Johnston、A.、Donovan、S.、Sparks、R.、Cunningham、C。、およびK. Summers、「セッション開始プロトコル（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。、「Secure/Multipurpose Internet Mail Extensions（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] Peterson、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] Niemi、A。、「イベント州の出版物のセッション開始プロトコル（SIP）拡張」、RFC 3903、2004年10月。イベント州の出版物のための」、RFC 3903、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.
[特性] Peterson、J.、Polk、J.、Sicker、D。、およびH. Tschofenig、「セッション開始プロトコル（SIP）の特性ベースの承認要件」、2005年2月の作業進行中。
Authors' Addresses
著者のアドレス
Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 US
ヘニングシュルツリンコロンビア大学コンピュータサイエンス学科450コンピューターサイエンスビル、ニューヨーク、ニューヨーク10027米国
Phone: +1 212 939 7004
EMail: 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イースト大統領ジョージブッシュターンパイクリチャードソン、テキサス75082米国
EMail: jmpolk@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。