RFC4412 日本語訳
4412 Communications Resource Priority for the Session InitiationProtocol (SIP). H. Schulzrinne, J. Polk. February 2006. (Format: TXT=79193 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group H. Schulzrinne
Request for Comments: 4412 Columbia U.
Category: Standards Track J. Polk
Cisco Systems
February 2006
Schulzrinneがコメントのために要求するワーキンググループH.をネットワークでつないでください: 4412年のコロンビアU.カテゴリ: 標準化過程J.ポークシスコシステムズ2006年2月
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(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.
このドキュメントはリソース優先権を伝えるための2つの新しいSession Initiationプロトコル(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
1. 序論…3 2. 用語…6 3. リソース優先権とリソース優先権を受け入れている一口ヘッダーフィールド…6 3.1. 'リソース優先権'ヘッダーフィールド…6 3.2. 'リソース優先権を受け入れてください'というヘッダーフィールド…8 3.3. 'リソース優先権'と'リソース優先権を受け入れてください'の用法…8 3.4. 'リソース優先権'オプションタグ…9 4. 受信される一口要素の動きは要求を最優先させました…9 4.1. 序論…9 4.2. 一般は判決を下します…9 4.3. 用法、リソース優先権でヘッダーを必要としてください…10 4.4. リソース優先権とのオプション要求…10
Schulzrinne & Polk Standards Track [Page 1] RFC 4412 SIP Resource Priority February 2006
Schulzrinneとポーク標準化過程[1ページ]RFC4412はリソース優先権2006年2月にちびちび飲みます。
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
4.5. 要求の優遇のためのアプローチ…11 4.5.1. 先取り…11 4.5.2. 優先権待ち行列…12 4.6. エラー条件…12 4.6.1. 序論…12 4.6.2. 知られている名前空間でない優先順位の値がありません…13 4.6.3. 認証失敗…13 4.6.4. 承認失敗…14 4.6.5. 不十分なリソース…14 4.6.6. 忙しい…14 4.7. 要素特有の振舞い…15 4.7.1. ユーザエージェントクライアントの振舞い…15 4.7.2. ユーザエージェントサーバの振舞い…15 4.7.3. プロキシの振舞い…16 5. 第三者認証…17 6. 遅れている互換性…17 7. 例…17 7.1. 簡単な呼び出し…18 7.2. 受信機は名前空間を理解していません…19 8. 複数の同時発生の名前空間を扱います…21 8.1. 一般は判決を下します…21 8.2. 有効な受注業務に関する例…21 8.3. 無効の受注業務に関する例…22 9. 名前空間を登録します…23 10. 名前空間定義…24 10.1. 序論…24 10.2. "DSN"名前空間…24 10.3. "DRSN"名前空間…25 10.4. "Q735"名前空間…25 10.5. 「ETS」名前空間…26 10.6. 「WPS」名前空間…26 11. セキュリティ問題…27 11.1. 一般所見…27 11.2. 認証と承認…27 11.3. 秘密性と保全…28 11.4. 匿名…29 11.5. サービス不能攻撃…29 12. IANA問題…30 12.1. 序論…30 12.2. 'リソース優先権'と'リソース優先権を受け入れてください'というヘッダーフィールドのIANA登録…30 12.3. Option Tagリソース優先権のためのIANA Registration…31 12.4. 応答コード417のためのIANA登録…31 12.5. IANAリソース優先権名前空間登録…31 12.6. IANA優先順位の値登録証明書…32 13. 承認…32 14. 参照…33
Schulzrinne & Polk Standards Track [Page 2] RFC 4412 SIP Resource Priority February 2006
Schulzrinneとポーク標準化過程[2ページ]RFC4412はリソース優先権2006年2月にちびちび飲みます。
1. Introduction
1. 序論
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ベースのサービスがあります。 このメモはSession Initiationプロトコル(SIP)[RFC3261]にかかわる瞬時通信アプリケーションをカバーするだけです、声過剰IP、マルチメディア会議、インスタントメッセージング、および存在を含んでいて。
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 Switched Telephone Networkと共にSIPゲートウェイによって溯源されたISUP(ISDN User Part)IAM(初期のAddress Message)(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プロトコル要素を加えます。
Schulzrinne & Polk Standards Track [Page 3] RFC 4412 SIP Resource Priority February 2006
Schulzrinneとポーク標準化過程[3ページ]RFC4412はリソース優先権2006年2月にちびちび飲みます。
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)。 'リソース優先権'ヘッダーフィールドはSIPユーザエージェントによって使用されるかもしれません、SIP要求に関する彼らの処理に影響を及ぼすためにPublic Switched Telephone Network(PSTN)ゲートウェイ、端末、およびSIPプロキシサーバを含んでいて、PSTN呼び出しに提供された優先権を含んでいて。 PSTNゲートウェイに関しては、振舞いはPSTNの類似の体系、例えば、ITU Recommendation Q.735.3[Q.735.3]優先順位づけメカニズムに翻訳されます、両方のIPへのPSTNとPSTNへのIP方向に。 ITU Recommendation 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. 要求は自分たちで点検しているかSIPプロキシなしでヘッダーフィールドを変更している電話網(例えば、Q.735.3[Q.735.3]の施設を使用する)の1つのマルチレベル優先権ドメインから別のドメインまでの情報を運ぶことができます。
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ゲートウェイかプロキシリソースの用法に影響しません。 さらに、どんなUserエージェントClient(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ルータの推進の振舞いかパケット推進優先権などのコミュニケーションリソースの使用に影響を及ぼしていない間、そのような影響を引き起こすのにこのヘッダーフィールドを使用するための手順は他のドキュメントで定義されるかもしれません。
Schulzrinne & Polk Standards Track [Page 4] RFC 4412 SIP Resource Priority February 2006
Schulzrinneとポーク標準化過程[4ページ]RFC4412はリソース優先権2006年2月にちびちび飲みます。
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.
リソース優先権メカニズムに参加しないRFC3261の既存の実装はRFC3261の正常な規則、セクション8.2.2に続きます: 「UASが要求におけるヘッダーフィールドを理解していないなら(すなわち、ヘッダーフィールドはこの仕様かどんなサポートしている拡大でも定義されません)、サーバは、そのヘッダーフィールドを無視して、メッセージを処理し続けなければなりません。」 したがって、要求がリソース優先権オプションタグがあるRequireヘッダーフィールドを含んでいない場合、このメカニズムの使用は完全に既存の実装に目に見えません。
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とレアル-時間Transportで[RFC3487]で定義されたプロトコル(RTP)[RFC3550]の見え透いたネットワークを扱います。 そのようなネットワークでは、すべてのネットワーク要素とSIPプロキシは変わりがない状態で有効なSIP要求を通り抜けます。 このメカニズムが縁のネットワークがリソース優先権メカニズムに気づかなく、特権を全くそのような要求に提供しないネットワークでしばしば配布されそうであるので、これは重要です。 そして、要求はメカニズムを意識しているSIP要素のPSTNゲートウェイかセットに達します。
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クライアントを変えないで、ユーザはこれらのいくつかのネットワークで認可された優先権取り扱いを得たがっています。 また、ただ一つの呼び出しは異なった政権と異なった優先権メカニズムを条件として動かされるSIP要素を横断するかもしれません。それらのプライオリティの中にグローバルな注文がないので、私たちは本書では名前空間と呼ばれるこれらの異なった優先権リストから得られた1つ以上の優先順位の値を含むという各要求を許します。 通常、それぞれの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)か他の適切な手段を使用して。
Schulzrinne & Polk Standards Track [Page 5] RFC 4412 SIP Resource Priority February 2006
Schulzrinneとポーク標準化過程[5ページ]RFC4412はリソース優先権2006年2月にちびちび飲みます。
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.
このドキュメントの残りは以下の通り構造化されます。 私たちは、セクション3における2つの新しいSIPヘッダーフィールドのためにセクション2の用語を構文を定義して、次に、セクション4で次々とプロトコルの振舞いについて説明します。 SIP要求(すなわち、先取りと待ち行列)の差別化された処理のための2つの主要なメカニズムがセクション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が、要求が複数の名前空間を含んでいるなら何が起こるかを論ずるか、または要素は1つ以上の名前空間を扱うことができます。 セクション9は名前空間登録証明書が、提供する必要があるという情報を列挙します。 セクション10はこのドキュメントを通して登録される5つの名前空間の特性を定義します。 安全保障問題はセクション11で考えられますが、このドキュメントは新しいセキュリティー対策を定義しません。セクション12は、IANA問題について論じて、このドキュメントに関連するパラメタを示します。
2. Terminology
2. 用語
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [RFC2119], and indicate requirement levels for compliant implementations.
本書では、キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTがこと解釈されるのは中でBCP14について説明しました、RFC2119[RFC2119]であり、対応する実装のために要件レベルを示すべきであるかをさせましょう。
3. The Resource-Priority and Accept-Resource-Priority SIP Header Fields
3. リソース優先権とリソース優先権を受け入れている一口ヘッダーフィールド
This section defines the 'Resource-Priority' and 'Accept-Resource-Priority' SIP header field syntax. Behavior is described in Section 4.
このセクションは'リソース優先権'と'リソース優先権を受け入れてください'SIPヘッダーフィールド構文を定義します。 振舞いはセクション4で説明されます。
3.1. The 'Resource-Priority' Header Field
3.1. 'リソース優先権'ヘッダーフィールド
The 'Resource-Priority' request header field marks a SIP request as desiring prioritized access to resources, as described in the introduction.
'リソース優先権'要求ヘッダーフィールドは序論で説明されるようにリソースへの最優先するアクセスを望んでいるとしてSIP要求をマークします。
Schulzrinne & Polk Standards Track [Page 6] RFC 4412 SIP Resource Priority February 2006
Schulzrinneとポーク標準化過程[6ページ]RFC4412はリソース優先権2006年2月にちびちび飲みます。
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-値=名前空間」 トークンnodot r」 r-優先権名前空間=優先権は1トークン-nodotトークン-nodot=*と等しいです。(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
リソース優先権: wps.3、dsn.flash
Schulzrinne & Polk Standards Track [Page 7] RFC 4412 SIP Resource Priority February 2006
Schulzrinneとポーク標準化過程[7ページ]RFC4412はリソース優先権2006年2月にちびちび飲みます。
Resource-Priority: wps.3
Resource-Priority: dsn.flash
リソース優先権: wps.3Resource-優先権: dsn.flash
3.2. The 'Accept-Resource-Priority' Header Field
3.2. 'リソース優先権を受け入れてください'というヘッダーフィールド
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.
いくつかの管理ドメインが、'リソース優先権を受け入れてください'というヘッダーの応答におけるそのドメインのあまりに多くの情報を明らかにする使用を無効にするのを選ぶかもしれません。 しかしながら、このヘッダーフィールドがトラブルシューティングで支援するとき、この振舞いはNOT RECOMMENDEDです。
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].)
以下のテーブルはRFC3261[RFC3261]のTable2で値を広げています。 (PRAとしてラベルされたPRACKメソッドが[RFC3262]で定義される、登録、(ラベルされたSUB)とNOTIFY([RFC3265]、[RFC3311]のUPDATE(UPD)メソッド、[RFC3428]のMESSAGE(MSG)メソッド、[RFC3515]のREFER(REF)メソッド、[RFC2976]のINFO(INF)メソッド、および[RFC3903]のPUBLISH(PUB)メソッドでNOT) メソッドとラベルされます)
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
ヘッダーフィールドどこプロキシINV ACK CAN BYE REG OPT PRA---------------------------------------------------------------- リソース優先権R amdr o o o o o o o Acceptリソース優先権200amdr o(○ ○ ○ ○ ○ Acceptリソース優先権417amdr 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
ヘッダーフィールドどこプロキシSUB NOT UPD MSG REF INF PUB---------------------------------------------------------------- リソース優先権R amdr o o o o o o o Acceptリソース優先権200amdr o o o o o o o Acceptリソース優先権417amdr o o o o o o o
Schulzrinne & Polk Standards Track [Page 8] RFC 4412 SIP Resource Priority February 2006
Schulzrinneとポーク標準化過程[8ページ]RFC4412はリソース優先権2006年2月にちびちび飲みます。
Other request methods MAY define their own handling rules; unless otherwise specified, recipients MAY ignore these header fields.
他の要求メソッドはそれら自身の取り扱い規則を定義するかもしれません。 別の方法で指定されない場合、受取人はこれらのヘッダーフィールドを無視するかもしれません。
3.4. The 'resource-priority' Option Tag
3.4. 'リソース優先権'オプションタグ
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にあります。
4. Behavior of SIP Elements That Receive Prioritized Requests
4. 受信される一口要素の動きは要求を最優先させました。
4.1. Introduction
4.1. 序論
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はOPTIONS要求の処理について説明します。 2つの基本的なリソース主張解決メカニズム、先取り、および待ち行列はセクション4.5で説明されます。 セクション4.6は、要求が失敗すると何が起こるかを説明します。 ユーザエージェントのクライアント、サーバ、およびプロキシサーバに特定の振舞いはセクション4.7でカバーされています。
4.2. General Rules
4.2. 総則
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要求メッセージに適切です。 最小限では、以下の要求タイプの実装は、Resource-優先権ヘッダーがこの仕様に従ってあるとサポートしなければなりません:
o INVITE [RFC3261]
o 招待[RFC3261]
o ACK [RFC3261]
o ACK[RFC3261]
o PRACK [RFC3262]
o PRACK[RFC3262]
o UPDATE [RFC3311]
o アップデート[RFC3311]
o REFER [RFC3515]
o 参照してください。[RFC3515]
Implementations SHOULD support the 'Resource-Priority' header field in the following request types:
実装SHOULDは、'リソース優先権'がヘッダーフィールドであると以下の要求タイプでサポートします:
o MESSAGE [RFC3428]
o メッセージ[RFC3428]
o SUBSCRIBE [RFC3265]
o 登録[RFC3265]
o NOTIFY [RFC3265]
o 通知してください。[RFC3265]
Schulzrinne & Polk Standards Track [Page 9] RFC 4412 SIP Resource Priority February 2006
Schulzrinneとポーク標準化過程[9ページ]RFC4412はリソース優先権2006年2月にちびちび飲みます。
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. それは、ローカルの方針によると、要求が優先順位が示した使用に認可されるのを確かめます。 要求が認可されていないなら、それはそれを拒絶します。 Security Considerations(セクション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で説明されるように。
4.3. Usage of Require Header with Resource-Priority
4.3. 用法、リソース優先権でヘッダーを必要としてください。
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(悪いExtension)で応じなければなりません。 そして、応答に'サポートされない'ヘッダーフィールドにおける「リソース優先権」を含んでいて、それは記載します。
The use of the 'resource-priority' option tag in 'Proxy-Require' header field is NOT RECOMMENDED.
オプションタグが中で'プロキシで必要である''リソース優先権'ヘッダーフィールドの使用はNOT RECOMMENDEDです。
4.4. OPTIONS Request with Resource-Priority
4.4. リソース優先権とのオプション要求
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要求を使用できます。 SHOULDがしかし、すべての有効なリソース値を列挙するOPTIONS応答、RP俳優で'リソース優先権を受け入れてください'というヘッダーフィールドを返す対応する実装は、そのような値を返さないか、または認可された要請者にそれらを返すためだけに構成されるかもしれません。
Following standard SIP behavior, OPTIONS responses MUST include the 'Supported' header field that includes the 'resource-priority' option tag.
標準のSIPの振舞いに続いて、OPTIONS応答は'リソース優先権'オプションタグを含んでいる'サポートしている'ヘッダーフィールドを含まなければなりません。
Schulzrinne & Polk Standards Track [Page 10] RFC 4412 SIP Resource Priority February 2006
Schulzrinneとポーク標準化過程[10ページ]RFC4412はリソース優先権2006年2月にちびちび飲みます。
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.
RFC3261、セクション11によると、ゼロの'前方へマックス'ヘッダーフィールド価値で要求を受け取るプロキシはOPTIONS要求に答えるかもしれません、UACがプロキシとユーザエージェントサーバの両方の能力を発見するのを許容して。
4.5. Approaches for Preferential Treatment of Requests
4.5. 要求の優遇のためのアプローチ
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俳優が要求に含まれた優先順位の値を理解していないなら何が起こるかと議論します。
4.5.1. Preemption
4.5.1. 先取り
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俳優は、より高い優先度の入って来るセッションのために場所を作る既存のセッションを中断するかもしれません。 セッションが異なった量の帯域幅か異なった数の回路を必要とするかもしれないので、ただ一つの、より高い優先度セッションは1つ以上の低優先度セッションを置き換えるかもしれません。 別の方法で注意されない場合、要求は等しい優先権の他の要求を先取りしません。 上で述べたように、SIP要求の処理自体は先取りされません。 したがって、プロキシがセッションを管理しないので、それらは先取りを実行しません。
[RFC4411] contains more details and examples of this behavior.
[RFC4411]はこの振舞いに関するその他の詳細と例を含んでいます。
UAS behavior for preemption is discussed in Section 4.7.2.1.
セクション4.7.2で.1に先取りのためのUASの振舞いについて議論します。
Schulzrinne & Polk Standards Track [Page 11] RFC 4412 SIP Resource Priority February 2006
Schulzrinneとポーク標準化過程[11ページ]RFC4412はリソース優先権2006年2月にちびちび飲みます。
4.5.2. Priority Queueing
4.5.2. 優先権待ち行列
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俳優は最優先する非空の待ち行列から要求を選択します。 1番目に関しては、来てください、そして、最初に役立たれた方針であり最も長い間待ちであるその待ち行列からの要求は役立たれています。 各待ち行列は有限数の未定の要求を保持できます。 新たに到着している要求のための1優先順位の値あたりの待ち行列が完全であるなら、要求はすぐに拒絶されます、ステータスコードがセクション4.6.5とセクション4.6.6で指定されている状態で。 さらに、優先権待ち行列方針はそれぞれの優先権のクラスのために待ち時間の限界を課すかもしれません。(それによって指定された待ち時間を超えている要求が待ち行列から放出されて、408(Timeoutを要求する)失敗応答は要請者に返されます)。
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(Timeoutを要求する)失敗応答に応じて、待ち低優先度要求を下げるかもしれません。 セッションがまだ確立されていないので、これは先取りを含意しません。
UAS behavior for queueing is discussed in Section 4.7.2.2.
セクション4.7.2で.2に待ち行列のためのUASの振舞いについて議論します。
4.6. Error Conditions
4.6. エラー条件
4.6.1. Introduction
4.6.1. 序論
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)のための不十分なリソースがあります。
Schulzrinne & Polk Standards Track [Page 12] RFC 4412 SIP Resource Priority February 2006
Schulzrinneとポーク標準化過程[12ページ]RFC4412はリソース優先権2006年2月にちびちび飲みます。
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.
私たちはオーダーにおけるこれらの誤り事件を扱います。それらはResource-優先権ヘッダーによる要求の処理で通常起きます。 しかしながら、このオーダーは強制されません。 例えば、ローカルの方針の問題として、特定のリソース値を役立つことができないか、列に並ばせることができないのを知っているRP俳優は承認を差し控えるかもしれません、結果を変えないで、処理負荷を加えるだけでしょう、したがって。
4.6.2. No Known Namespace or Priority Value
4.6.2. 知られている名前空間でない優先順位の値がありません。
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(未知のResource-優先権)応答コードによる要求を拒絶しなければなりません。
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と共有しないところにないでしょう、したがって、弁護(1)をデフォルトにするのが必要ですが、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要求は1'リソース優先権'のヘッダーフィールドを含むことができます。 要求が、異なった管理ドメインを横断する必要があるなら、これが必要です、それぞれそれ自身の有効なリソース値のセットで。 例えば、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(未知のResource-優先権)応答は'リソース優先権を受け入れてください'という許容できるリソース値を列挙するヘッダーフィールドを含むかもしれません。
4.6.3. Authentication Failure
4.6.3. 認証失敗
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(プロキシAuthentication Required)応答を返します。
Schulzrinne & Polk Standards Track [Page 13] RFC 4412 SIP Resource Priority February 2006
Schulzrinneとポーク標準化過程[13ページ]RFC4412はリソース優先権2006年2月にちびちび飲みます。
4.6.4. Authorization Failure
4.6.4. 承認失敗
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(禁じられる)応答を返さなければなりません。
4.6.5. Insufficient Resources
4.6.5. 不十分なリソース
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(サービスUnavailable)で応じます。
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(Acceptable Hereでない)応答は、RP俳優がメディア経路の有用性による要求を拒絶しているのを示します、不十分なゲートウェイリソースなどのように。 その場合、[RFC3261]は、488応答SHOULDが拒絶の理由がある'警告'ヘッダーフィールドを含んでいると忠告します。 警告コード370(不十分なBandwidth)は典型的です。
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(Timeoutを要求する)を返すでしょう。
4.6.6. Busy
4.6.6. 忙しい
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に到着すると、リソース主張は起こります、UASがちょうど1つの系列外観を持っているか、またはすべての系列外観に活発な呼び出しを持っているので。 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(Timeoutを要求する)を返すでしょう。
If a proxy gets 486 (Busy Here) responses on all branches, it can then return a 600 (Busy Everywhere) response to the caller.
プロキシがすべてのブランチで486(忙しいHere)の応答を得るなら、それは訪問者への600(忙しいEverywhere)応答を返すことができます。
Schulzrinne & Polk Standards Track [Page 14] RFC 4412 SIP Resource Priority February 2006
Schulzrinneとポーク標準化過程[14ページ]RFC4412はリソース優先権2006年2月にちびちび飲みます。
4.7. Element-Specific Behaviors
4.7. 要素特異的行動
4.7.1. User Agent Client Behavior
4.7.1. ユーザエージェントクライアントの振舞い
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 SHOULD、1つ以上のリソースがただ一つの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(未知のResource-優先権)応答を受けると、UAC MAYは同じであるか異なったリソース値でその後の要求を試みます。 利用可能であるなら、それは'リソース優先権を受け入れてください'というヘッダーフィールドで返された値のセットからリソース値を認可しましたSHOULDが、選ぶ。
4.7.1.1. User Agent Client Behavior with a Preemption Algorithm
4.7.1.1. 先取りアルゴリズムとのユーザエージェントクライアントの振舞い
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は、BYE要求におけるReasonヘッダーフィールドでセッションがなぜ終えられたかがわかるのを理解しなければなりません、[RFC4411]で議論するように。
4.7.1.2. User Agent Client Behavior with a Queueing Policy
4.7.1.2. 待ち行列方針とのユーザエージェントクライアントの振舞い
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 MUSTが現在、容量でいるRP俳優から182(列に並ばせられる)応答を受けるように準備されて、それだけがオリジナルの要求を待ち行列に入れました。 UAC MAYは、これがユーザが失敗したと呼び出しを解釈するのを防ぐために何らかのオーディオの、または、視覚の指示でユーザへ状態を列に並ばせたのを示します。
4.7.2. User Agent Server Behavior
4.7.2. ユーザエージェントサーバの振舞い
The precise effect of the 'Resource-Priority' indication depends on the type of UAS, the namespace, and local policy.
'リソース優先権'指示の正確な効果はUASのタイプ、名前空間の、そして、ローカルの方針によります。
4.7.2.1. User Agent Servers and Preemption Algorithm
4.7.2.1. ユーザエージェントサーバと先取りアルゴリズム
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
作成者には、どうすなわち、複数の系列臨場感、デバイスがあるIP電話での先取りにそれを実装するかの多くの選択があります。
Schulzrinne & Polk Standards Track [Page 15] RFC 4412 SIP Resource Priority February 2006
Schulzrinneとポーク標準化過程[15ページ]RFC4412はリソース優先権2006年2月にちびちび飲みます。
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.
複数の同時のセッションに扱うことができます。 当然、同時のセッションの数がそのデバイスでくたくたになったなら、セッションのひとりは、取り替えられる必要があります。 デバイスに予備セッションがあるなら、実装は、より高い優先度呼び出しの到着に訪問される人を警告するのを選ぶかもしれません。 また、詳細は地方か名前空間方針で設定されるかもしれません。
[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'の'予約')を許容して、それぞれの理由に関する呼び出し流れの例を含んでいます。
4.7.2.2. User Agent Servers and Queue-Based Policy
4.7.2.2. ユーザエージェントサーバと待ち行列ベースの方針
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].
その要素のリソースが忙しいなら、この仕様SHOULDで言いなりになっているUASは182(列に並ばせられる)応答を生成します、要求を扱って、最終的な応答を提供できるまで。 そのような暫定的なメッセージの頻度は[RFC3261]によって決定されます。
4.7.3. Proxy Behavior
4.7.3. プロキシの振舞い
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].
RFC3261のセクション23によると、S/MIMEカプセル化が使用されるなら、特別な問題は適用されます。 セクション3.3に表にされるように、'リソース優先権'ヘッダーフィールドは、プロキシが変更できて、その結果、保全から免除されていて、照合がセクション23.4.1で.1RFC3261について説明したということです。 プロキシによって点検されるか、または変更されるのが必要であるかもしれないので、また、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プロキシは、要求か差し込みの'リソース優先権'新しい'リソース優先権'ヘッダーを格下げするか、またはアップグレードさせるかもしれません。
Schulzrinne & Polk Standards Track [Page 16] RFC 4412 SIP Resource Priority February 2006
Schulzrinneとポーク標準化過程[16ページ]RFC4412はリソース優先権2006年2月にちびちび飲みます。
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.
statefulプロキシが特定のリソース優先順位を認可して、リソース優先順位を含む応答に差別化された処理を提供するなら、プロキシSHOULDは馴れ合っているユーザエージェントが人工的に優先順位を上げるのを防ぐために応答に含まれたどんなより高い値も無視します。
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で説明されたユーザエージェントサーバのように同じです。
5. Third-Party Authentication
5. 第三者認証
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俳優が要請者のアイデンティティを決定するのを助けることができます。
6. Backwards Compatibility
6. 遅れている互換性
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システムと互換性があった状態で完全に遅れています。 メカニズムが上げられるのではなく、規格を提供できるだけであるのを理解していないシステムが優先権を修理します。 ユーザエージェントサーバとプロキシは、まさしくいかなる他の未知のヘッダーフィールドのようにもどんな'リソース優先権'ヘッダーフィールドも無視して、次に、いかなる他の要求のようにも要求を扱うことができます。 当然、要求はまだ成功しているかもしれません。
7. Examples
7. 例
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交換は、RFC3665[RFC3665]と同じであり、簡潔さのために省略されます。
Schulzrinne & Polk Standards Track [Page 17] RFC 4412 SIP Resource Priority February 2006
Schulzrinneとポーク標準化過程[17ページ]RFC4412はリソース優先権2006年2月にちびちび飲みます。
7.1. Simple Call
7.1. 簡単な呼び出し
User A User B
| |
| INVITE F1 |
|----------------------->|
| 180 Ringing F2 |
|<-----------------------|
| |
| 200 OK F3 |
|<-----------------------|
| ACK F4 |
|----------------------->|
| Both Way RTP Media |
|<======================>|
| |
ユーザはユーザBです。| | | F1を招いてください。| |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、| 180 F2を鳴らすこと。| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、| 200 OK F3| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| ACK F4| |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、| 両方、道のRTPメディア| |<===========>|、|、|
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.
このシナリオでは、User Aは直接User Bに呼び出しを終了します。 AからBまでの呼び出しはリソース優先権指示でマークされます。
F1 INVITE User A -> User B
F1はユーザのために->ユーザ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: ...
INVITE一口: UserB@biloxi.example.com SIP/2.0Via: 一口/2.0/TCP client.atlanta.example.com: 5060; ブランチは前方へz9hG4bK74bf9マックスと等しいです: 70 From: BigGuy<一口: UserA@atlanta.example.com 、gt;、;=9fxced76sl To:にタグ付けをしてください LittleGuy<一口: UserB@biloxi.example.com 、gt;、呼び出しID: 3848276298220188511@atlanta.example.com CSeq: 1 リソース優先権を招待してください: dsn.flash Contact: <一口: UserA@client.atlanta.example.com;transport がtcpと等しい、gt;、コンテントタイプ: sdp Contentアプリケーション/長さ: ...
...
...
F2 180 Ringing User B -> User A
ユーザB->ユーザAに電話をするF2 180
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
以下を通って鳴る一口/2.0 180 一口/2.0/TCP client.atlanta.example.com: 5060; ブランチ=z9hG4bK74bf9;は=192.0.2.101From:を受けました。 BigGuy<一口: UserA@atlanta.example.com 、gt;、;=9fxced76sl To:にタグ付けをしてください LittleGuy<一口: UserB@biloxi.example.com 、gt;、; タグは8321234356呼び出しIDと等しいです: 3848276298220188511@atlanta.example.com CSeq: 1 接触を招いてください: <一口: UserB@client.biloxi.example.com;transport がtcpと等しい、gt;、コンテンツの長さ: 0
Schulzrinne & Polk Standards Track [Page 18] RFC 4412 SIP Resource Priority February 2006
Schulzrinneとポーク標準化過程[18ページ]RFC4412はリソース優先権2006年2月にちびちび飲みます。
F3 200 OK User B -> User A
F3 200OKユーザ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: ...
以下を通って一口/2.0 200OK 一口/2.0/TCP client.atlanta.example.com: 5060; ブランチ=z9hG4bK74bf9;は=192.0.2.101From:を受けました。 BigGuy<一口: UserA@atlanta.example.com 、gt;、;=9fxced76sl To:にタグ付けをしてください LittleGuy<一口: UserB@biloxi.example.com 、gt;、; タグは8321234356呼び出しIDと等しいです: 3848276298220188511@atlanta.example.com CSeq: 1 接触を招いてください: <一口: UserB@client.biloxi.example.com;transport がtcpと等しい、gt;、コンテントタイプ: sdp Contentアプリケーション/長さ: ...
...
...
7.2. Receiver Does Not Understand Namespace
7.2. 受信機は名前空間を理解していません。
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(未知のResource-優先権)ステータスコードを返します。 私たちは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 |
|<======================>|
ユーザはユーザBです。| | | F1を招いてください。| |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、| 417 R-PはF2に失敗しました。| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| ACK F3| |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| F4を招待してください。| |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、| 180 F5を鳴らすこと。| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| 200 OK F6| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| ACK F7| |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| 両方、道のRTPメディア| |<===========>|
Schulzrinne & Polk Standards Track [Page 19] RFC 4412 SIP Resource Priority February 2006
Schulzrinneとポーク標準化過程[19ページ]RFC4412はリソース優先権2006年2月にちびちび飲みます。
F1 INVITE User A -> User B
F1はユーザのために->ユーザ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>
INVITE一口: UserB@biloxi.example.com SIP/2.0Via: 一口/2.0/TCP client.atlanta.example.com: 5060; ブランチは前方へz9hG4bK74bf9マックスと等しいです: 70 From: BigGuy<一口: UserA@atlanta.example.com 、gt;、;=9fxced76sl To:にタグ付けをしてください LittleGuy<一口: UserB@biloxi.example.com 、gt;、呼び出しID: 3848276298220188511@atlanta.example.com CSeq: 1 招待は以下を必要とします。 リソース優先権Resource-優先権: dsn.flash Contact: <一口: UserA@client.atlanta.example.com;transport がtcpと等しい、gt。
Content-Type: application/sdp Content-Length: ...
コンテントタイプ: sdp Contentアプリケーション/長さ: ...
...
...
F2 417 Resource-Priority failed User B -> User A
F2 417リソース優先権はUser B->User 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
以下を通って一口/2.0 417の未知のリソース優先権 一口/2.0/TCP client.atlanta.example.com: 5060; ブランチ=z9hG4bK74bf9;は=192.0.2.101From:を受けました。 BigGuy<一口: UserA@atlanta.example.com 、gt;、;=9fxced76sl To:にタグ付けをしてください LittleGuy<一口: UserB@biloxi.example.com 、gt;、; タグは8321234356呼び出しIDと等しいです: 3848276298220188511@atlanta.example.com CSeq: 1つの招待、リソース優先権を受け入れてください: q735.0、q735.1、q735.2、q735.3、q735.4 Contact: <一口: UserB@client.biloxi.example.com;transport がtcpと等しい、gt;、コンテントタイプ: sdp Contentアプリケーション/長さ: 0
F3 ACK User A -> User B
F3 ACKユーザは->ユーザ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一口: UserB@biloxi.example.com SIP/2.0Via: 一口/2.0/TCP client.atlanta.example.com: 5060; ブランチは前方へz9hG4bK74bd5マックスと等しいです: 70 From: BigGuy<一口: UserA@atlanta.example.com 、gt;、;=9fxced76sl To:にタグ付けをしてください LittleGuy<一口: UserB@biloxi.example.com 、gt;、; タグは8321234356呼び出しIDと等しいです: 3848276298220188511@atlanta.example.com CSeq: 1 ACKコンテンツの長さ: 0
Schulzrinne & Polk Standards Track [Page 20] RFC 4412 SIP Resource Priority February 2006
Schulzrinneとポーク標準化過程[20ページ]RFC4412はリソース優先権2006年2月にちびちび飲みます。
F4 INVITE User A -> User B
F4はユーザのために->ユーザ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>
INVITE一口: UserB@biloxi.example.com SIP/2.0Via: 一口/2.0/TCP client.atlanta.example.com: 5060; ブランチは前方へz9hG4bK74bf9マックスと等しいです: 70 From: BigGuy<一口: UserA@atlanta.example.com 、gt;、;=9fxced76sl To:にタグ付けをしてください LittleGuy<一口: UserB@biloxi.example.com 、gt;、呼び出しID: 3848276298220188511@atlanta.example.com CSeq: 2 招待は以下を必要とします。 リソース優先権Resource-優先権: q735.3接触: <一口: UserA@client.atlanta.example.com;transport がtcpと等しい、gt。
Content-Type: application/sdp Content-Length: ... ...
コンテントタイプ: sdp Contentアプリケーション/長さ: ... ...
8. Handling Multiple Concurrent Namespaces
8. 複数の同時発生の名前空間を扱います。
8.1. General Rules
8.1. 総則
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俳優が複数の名前空間を理解しているなら、すべてのリソース値の向こう側にこれらの名前空間に注文される地方の合計を作成しなければなりません、各名前空間の中で注文する親類を維持して。 同じ注文が管理ドメインの向こう側に使用されるのは、RECOMMENDEDです。 しかしながら、そのような注文がある要件が全くすべての管理ドメインのむこうに同じようにありません。
8.2. Examples of Valid Orderings
8.2. 有効な受注業務に関する例
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つの名前空間、foo、およびバーを支えるRP俳優の例のセットです。 次に、2、および次に、1(最も低い)、およびバーの優先順位の値は、Fooの優先順位の値が3(最も高い)であり、C(最も高い)と、次に、Bと、そして、A(最も低い)です。
Schulzrinne & Polk Standards Track [Page 21] RFC 4412 SIP Resource Priority February 2006
Schulzrinneとポーク標準化過程[21ページ]RFC4412はリソース優先権2006年2月にちびちび飲みます。
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.3Foo.3Bar.C(最優先)Foo.2Bar.C Foo.3Foo.1かFoo.2かFoo.2Bar.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.3Bar.B(等しい優先権(先入れ先出し法)で扱われた両方)かFoo.2Bar.A(等しい優先権(先入れ先出し法)で扱われた両方)Foo.1(最も低い優先度)
Bar.C (highest priority)
Foo.3
or Foo.2
Foo.1 (lowest priority)
Bar.C(最優先)Foo.3かFoo.2Foo.1(最も低い優先度)
In the last example above, Bar.A and Bar.B are ignored.
最後の例では、上では、Bar.AとBar.Bが無視されます。
8.3. Examples of Invalid Orderings
8.3. 無効の受注業務に関する例
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
例1の例2の例3--------- --------- --------- Foo.3Foo.3Bar.C Foo.2Bar.A Foo.1Foo.1かFoo.2かFoo.3Bar.C Bar.B Foo.2Bar.A Foo.1Bar.A Bar.B Bar.C Bar.B
Example 4
---------
Bar.C
Foo.1 Bar.B
or Foo.3 Bar.A
Foo.2
例4--------- Bar.C Foo.1Bar.BかFoo.3Bar.A Foo.2
Schulzrinne & Polk Standards Track [Page 22] RFC 4412 SIP Resource Priority February 2006
Schulzrinneとポーク標準化過程[22ページ]RFC4412はリソース優先権2006年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 Example1では、Bar.AをBar.Bより高く注文します。
o In Example 2, Bar.A is ordered higher than Bar.B and Bar.C.
o Example2では、Bar.AをBar.BとBar.Cより高く注文します。
o In Example 3, Foo.1 is ordered higher than Foo.2 and Foo.3.
o Example3では、Foo.1をFoo.2とFoo.3より高く注文します。
o In Example 4, Foo.1 is ordered higher than Foo.3 and Foo.2.
o Example4では、Foo.1をFoo.3とFoo.2より高く注文します。
9. Registering Namespaces
9. 名前空間を登録します。
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.
Resource-優先権ヘッダーフィールドの使用を考える組織は、名前空間と優先順位の値の既存の組み合わせが彼らの需要を満たすかどうか調査するべきです。 例えば、世界中の非常時の第一応答者は、将来のネットワークでこのメカニズムを優遇に利用するのを議論しています。 既存のIANAを再利用する管内SHOULD試みは可能であるところに名前空間を登録しました、このドキュメントの目標が1同じ目的に役立つ管轄あたりのユニークな名前空間を持たないことであるので、優先順位の同じ用法で。 織り込む機能で1つの名前空間を別のものに写像する必要があると、これは、相互運用性を大いに増強して、開発時間を減少させて、たぶん今後の混乱を抑えるでしょう。
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]の'規格Action'方針に従って、Standards Track 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 Resource-優先権ヘッダーフィールドのために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、プロキシ)を考慮に入れて。
Schulzrinne & Polk Standards Track [Page 23] RFC 4412 SIP Resource Priority February 2006
Schulzrinneとポーク標準化過程[23ページ]RFC4412はリソース優先権2006年2月にちびちび飲みます。
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 名前空間は、一口パラメタResource-優先権優先順位の値登録の中のIANA登録のための相対的な優先順で優先順位の値の既存のリストに参照をつけるか、または優先順位の値の新しい有限リストを定義するかもしれません。 別の方法で指定されない場合これは原因相互運用性問題を追加されるので新しい優先順位の値SHOULD NOTが特定の名前空間に関連している以前に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 参考書類がどんな新しいWarningヘッダーフィールドも指定して、説明しなければならない、警告する、(RFC3261、セクション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 Resource-優先権Namespace登録に含められています:
Intended New New resp.
Namespace Levels algorithm warn-code code Reference
--------- ------ ---------------- --------- -------- ---------
<label> <# of <preemption <new warn <new resp. <RFC>
levels> or queue> code> code>
意図しているNew New resp。 名前空間Levelsアルゴリズム、警告する、Referenceをコード化してください。--------- ------ ---------------- --------- -------- --------- <先取り<新しいことの<ラベル><#は<の新しいrespに警告します。 <RFC>レベルの>か待ち行列>コード>コード>。
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.
新しい応答コード、拒絶コード、または誤りの振舞いの情報が省略されるなら、名前空間がどんな新しいパラメタも振舞いも定義しないと思われることになっています。
10. Namespace Definitions
10. 名前空間定義
10.1. Introduction
10.1. 序論
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つのユニークな名前空間を定義します: IANAとの彼らの登録を構成するDSN、DRSN、Q735、ETS、およびWPS。 それぞれのIANA登録はセクション9で定義された一面を含んでいます。 認識可能性によって、私たちは、大文字で名前空間をラベルしますが、名前空間名が大文字と小文字を区別しなく、通例にプロトコル要求で小文字に表されることに注意します。
10.2. The "DSN" Namespace
10.2. "DSN"名前空間
The DSN namespace comes from the name of a US government network called "The Defense Switched Network".
DSN名前空間は「国防省電話交換網」と呼ばれる米国政府ネットワークの名前から来ます。
Schulzrinne & Polk Standards Track [Page 24] RFC 4412 SIP Resource Priority February 2006
Schulzrinneとポーク標準化過程[24ページ]RFC4412はリソース優先権2006年2月にちびちび飲みます。
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)を使用します。
10.3. The "DRSN" Namespace
10.3. "DRSN"名前空間
The DRSN namespace comes from the name of a US government network, called "The Defense RED Switched Network".
DRSN名前空間は「ディフェンス赤の交換網」と呼ばれる米国政府ネットワークの名前から来ます。
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名前空間は1つのアルゴリズムの局面でDSNとQ735名前空間と異なります。 'フラッシュオーバーライドオーバーライド'優先順位の値のための振舞いは他の値と異なっています。 通常、要求は等しい優先権のものを先取りしませんが、不十分なリソースがあれば、'要求が別の1つを置き換える新たに到着している'フラッシュオーバーライドオーバーライドは優先権と等しいです。 また、'フラッシュオーバーライドオーバーライド'要求が'フラッシュオーバーライド'だけとして自らを守ると言うとしてこれを言い表すことができます。
10.4. The "Q735" Namespace
10.4. "Q735"名前空間
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]は、Multi-レベルPrecedenceとPreemption(MLPP)に、操作上同等なDSN仕様の商業バージョンになるように作成されました。 Q735名前空間はここ、同じ方法で定義されます。
Schulzrinne & Polk Standards Track [Page 25] RFC 4412 SIP Resource Priority February 2006
Schulzrinneとポーク標準化過程[25ページ]RFC4412はリソース優先権2006年2月にちびちび飲みます。
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.
先取り(セクション4.5.1)アルゴリズムによると、Q735名前空間は作動します。
10.5. The "ETS" Namespace
10.5. 「ETS」名前空間
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に責任がある組織ですが、ETS名前空間が名前に「政府非常時のテレコムサービス」(または、GETS)と呼ばれる米国政府テレコムサービスの名前に間接的に由来している、それ、IPサービスの上で得ます。サービスは「非常時のテレコムサービス」を表します。
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の.2ets.1(最も高い)の.4ets.3ets ets.0
The ETS namespace operates according to the priority queueing algorithm (Section 4.5.2).
優先権待ち行列アルゴリズム(セクション4.5.2)によると、ETS名前空間は作動します。
10.6. The "WPS" Namespace
10.6. 「WPS」名前空間
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の.2wps.1(最も高い)の.4wps.3wps wps.0
Schulzrinne & Polk Standards Track [Page 26] RFC 4412 SIP Resource Priority February 2006
Schulzrinneとポーク標準化過程[26ページ]RFC4412はリソース優先権2006年2月にちびちび飲みます。
The WPS namespace operates according to the priority queueing algorithm (Section 4.5.2).
優先権待ち行列アルゴリズム(セクション4.5.2)によると、WPS名前空間は作動します。
11. Security Considerations
11. セキュリティ問題
11.1. General Remarks
11.1. 概評
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.
以下で、私たちは認証、承認局面、秘密性、プライバシー要件、サービスの否定攻撃に対する保護、および匿名要件について説明します。 当然、RFC3261[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](RFC3261のセクション26.2、およびRFC3261のセクション22で説明されるDigest Authentication[RFC2617]で説明される'一口'URI体系)の上でSIPを実装しなければなりません。 また、さらに、この拡張子がSHOULDであるとサポートするユーザエージェントがこの拡張子を使用する署名すると考慮するRFC3261のセクション23と要求の上の署名の検証で説明されるようにS/MIME[RFC3851]を実装します。
11.2. Authentication and Authorization
11.2. 認証と承認
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.
ある非常時の条件のもとでは、その認証と承認メカニズムを含むネットワークインフラは攻撃されているかもしれません。
Schulzrinne & Polk Standards Track [Page 27] RFC 4412 SIP Resource Priority February 2006
Schulzrinneとポーク標準化過程[27ページ]RFC4412はリソース優先権2006年2月にちびちび飲みます。
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認証のためのRECOMMENDEDです。 ダイジェスト認証は、パーティーが一般的な秘密を共有するのを必要として、その結果、管理ドメインの向こう側に使用を制限します。 リソース優先権SHOULDを使うSIPシステムは少なくとも保全のために[RFC3261]のセクション23で説明されるように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.
特色ベースの承認[TRAIT]は、「アイデンティティに関連している属性の承認サービスで主張を伴っ」て、このアプリケーションに、適切であるかもしれません。 特色ベースの承認で、ネットワーク要素は、要求が特定のタイプのサービスを得るのが認可されることを直接証明書を点検することによって、決定できます、ユーザアイデンティティを承認に変換するマッピングメカニズムに相談する必要はなくて。
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.
承認は要求された目的地などの訪問者のアイデンティティ以外に要素に基づくかもしれません。 また、名前空間はここで説明された基線より厳しい特定の認証か承認問題を課すかもしれません。
11.3. Confidentiality and Integrity
11.3. 秘密性と保全
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'、'組織'、および'受けることがある'ヘッダーフィールドは特に機密の情報に関する例です。 システムは、他のトランスポート層かネットワーク層セキュリティがメカニズムであるとTLSを使用して、輸送レベルで暗号化を実装しなければならなくて、実装するかもしれません。UACs SHOULDは、安全な輸送協会を目的地に要求するのに「一口」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]で運ばれたメッセージ断片でカプセル化することができます。 この仕様の目的のための有効な認証であるとMIMEによってS/署名された状態で考えられるために
Schulzrinne & Polk Standards Track [Page 28] RFC 4412 SIP Resource Priority February 2006
Schulzrinneとポーク標準化過程[28ページ]RFC4412はリソース優先権2006年2月にちびちび飲みます。
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メッセージか断片が最小限でDate、To、From、Call-ID、およびResource-優先権ヘッダーフィールドを含まなければなりません。 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.
Resource-優先権ヘッダーフィールドか優先順位の値を格下げする取り外しは追加の機会を全く敵に提供しません、中央のその男性が単に低下するか、そうでなければ、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要素だけが適切に署名されないResource-優先権ヘッダーフィールドを信じるでしょう。 他のものは、独自に要求を認証する必要があるでしょう。 したがって、Resource-優先権ヘッダーフィールドか優先順位の値をアップグレードさせる挿入には、失敗するという要求を引き起こす以外に、さらなるセキュリティ意味が全くありません(前のパラグラフにおける議論を見てください)。
11.4. Anonymity
11.4. 匿名
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]で説明されたネットワークによって断言されたアイデンティティと一般的なプライバシーメカニズムを使用して、彼らは要求の目的地に向かって匿名のままで残るかもしれません。
11.5. Denial-of-Service Attacks
11.5. サービス不能攻撃
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攻撃はネットワーク自体の上と、そして、その認証と承認メカニズムの上で着手されるかもしれません。 注意されるように、システムは権限のないユーザが命令することができる状態、計算、およびネットワーク資源の量を最小にするはずです。 システムは、可到達性が確かめられていないネットワーク・アドレスに1つ以上のパケットのトランスミッションを引き起こすことによって、攻撃を増幅してはいけません。
Schulzrinne & Polk Standards Track [Page 29] RFC 4412 SIP Resource Priority February 2006
Schulzrinneとポーク標準化過程[29ページ]RFC4412はリソース優先権2006年2月にちびちび飲みます。
12. IANA Considerations
12. IANA問題
12.1. Introduction
12.1. 序論
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).
このセクションはResource-優先権と優先権値(セクション12.6)のために2個の新しいSIPヘッダー(セクション12.2)、1個のSIPオプションタグ(セクション12.3)、1つの新しい4xxエラーコード(セクション12.4)、Resource優先権名前空間(セクション12.5)のためのIANAの一口パラメタ部の中の新しい登録、およびIANAの一口パラメタ部の中の新しい登録を定義します。
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 Change Process[RFC3427]は新しいSIP拡張ヘッダーの登録のための方針を確立します。 リソース優先権名前空間と優先順位の値はSIP拡張ヘッダーのものに同様の相互運用性要件を持っています。 その結果、新しいリソース優先権名前空間と優先順位の値の登録は、RFC3427で指定された拡張ヘッダー承認審査方式を使用することで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年のヘッダー名: 'リソース優先権'Compactは形成します: なし
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年のヘッダー名: リソース優先権を受け入れているCompactは形成します: なし
Schulzrinne & Polk Standards Track [Page 30] RFC 4412 SIP Resource Priority February 2006
Schulzrinneとポーク標準化過程[30ページ]RFC4412はリソース優先権2006年2月にちびちび飲みます。
12.3. IANA Registration for Option Tag resource-priority
12.3. Option Tagリソース優先権のためのIANA Registration
RFC number: 4412
Name of option tag: 'resource-priority'
Descriptive text: Indicates or requests support for the resource
priority mechanism.
RFC番号: 4412年のオプションタグの名: 'リソース優先権'Descriptiveテキスト: リソース優先権メカニズムのサポートを示すか、または要求します。
12.4. IANA Registration for Response Code 417
12.4. 応答コード417のためのIANA登録
RFC number: 4412 Response code: 417 Default reason phrase: Unknown Resource-Priority
RFC番号: 4412年の応答コード: 417デフォルト理由句: 未知のリソース優先権
12.5. IANA Resource-Priority Namespace Registration
12.5. IANAリソース優先権名前空間登録
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の一口パラメタ部での新しい登録(「リソース優先権名前空間」)を作成してあります、以下のこのテーブルと同様の形を取って:
Intended New warn- New resp.
Namespace Levels Algorithm code code Reference
--------- ------ ---------------- --------- --------- ---------
dsn 5 preemption no no [RFC4412]
意図しているNewは新しいrespに警告します。 名前空間Levels AlgorithmコードコードReference--------- ------ ---------------- --------- --------- --------- dsn5先取りはノーではありません。[RFC4412]
drsn 6 preemption no no [RFC4412]
drsn6先取りはノーではありません。[RFC4412]
q735 5 preemption no no [RFC4412]
q735 5先取りはノーではありません。[RFC4412]
ets 5 queue no no [RFC4412]
ets5はいいえを全く列に並ばせません。[RFC4412]
wps 5 queue no no [RFC4412]
wps5はいいえを全く列に並ばせません。[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.
伝説------ 名前空間を特定するユニークが結ぶ名前空間。 名前空間の中で優先順位の値の数を平らにします。 この名前空間を実装するSIP要素のアルゴリズムのIntendedの操作上の動き。 新しいWarnがNew Warning Codesをコード化する、(警告する、)、この名前空間で、導入します。 新しいRespこの名前空間によって紹介されたNew SIP応答コードをコード化してください。 参照IETFはこの名前空間の参照を記録します。
Schulzrinne & Polk Standards Track [Page 31] RFC 4412 SIP Resource Priority February 2006
Schulzrinneとポーク標準化過程[31ページ]RFC4412はリソース優先権2006年2月にちびちび飲みます。
12.6. IANA Priority-Value Registrations
12.6. IANA優先順位の値登録証明書
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の一口パラメタ部での新しい登録(「リソース優先権優先順位の値」)を作成してあります、以下のこのテーブルと同様の形を取って:
Namespace: drsn
Reference: RFC 4412
Priority-Values (least to greatest): "routine", "priority",
"immediate", "flash", "flash-override", "flash-override-override"
名前空間: drsn Reference: RFC4412Priority-値(最もすばらしく最少の): 「通常」の、そして、「優先権」の、そして、「即座」の「フラッシュ」、「フラッシュオーバーライド」、「フラッシュオーバーライドオーバーライド」
Namespace: dsn
Reference: RFC 4412
Priority-Values (least to greatest): "routine", "priority",
"immediate", "flash", "flash-override"
名前空間: dsn Reference: RFC4412Priority-値(最もすばらしく最少の): 「通常」の、そして、「優先権」の、そして、「即座」の「フラッシュ」、「フラッシュオーバーライド」
Namespace: q735 Reference: RFC 4412 Priority values (least to greatest): "4", "3", "2", "1", "0"
名前空間: q735参照: RFC4412Priority値(最もすばらしく最少の): "4", "3", "2", "1", "0"
Namespace: ets Reference: RFC 4412 Priority values (least to greatest): "4", "3", "2", "1", "0"
名前空間: ets Reference: RFC4412Priority値(最もすばらしく最少の): "4", "3", "2", "1", "0"
Namespace: wps Reference: RFC 4412 Priority values (least to greatest): "4", "3", "2", "1", "0"
名前空間: wps Reference: RFC4412Priority値(最もすばらしく最少の): "4", "3", "2", "1", "0"
13. Acknowledgements
13. 承認
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.
ベン・キャンベル、ケンCarlberg、ポールKyzivat、Rohanマーイ、アリソン・マンキン、ザビエルMarjou、Piersオーハンロン、マイク・ピアス、Samir Srivastava、およびデール・ウォーリーは役に立つコメントを提供しました。
Dean Willis provided much help with this effort.
ディーン・ウィリスはこの取り組みを多くの助けに提供しました。
Martin Dolly, An Nguyen, and Niranjan Sandesara assisted with the ETS and WPS namespaces.
マーチン・ドリー、An Nguyen、およびNiranjan SandesaraはETSとWPS名前空間を助けました。
Janet Gunn helped improve the text on queueing-based priority.
ジャネット・ガンは、待ち行列ベースの優先権に関するテキストを改良するのを助けました。
Schulzrinne & Polk Standards Track [Page 32] RFC 4412 SIP Resource Priority February 2006
Schulzrinneとポーク標準化過程[32ページ]RFC4412はリソース優先権2006年2月にちびちび飲みます。
14. References
14. 参照
14.1. Normative References
14.1. 引用規格
[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、1990年7月[I.255.3]国際電気通信組合と、「サービス統合ディジタル網(ISDN)--一般構造体とサービス能力--マルチレベル先行と先取り」
[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]国際Telecommunications Union、「Signalling System No.7を使用して、利益共同体の補っているサービスのための3記述を上演してください」 Recommendation 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.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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問題部に書くためのガイドライン」BCP26、RFC2434(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.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、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、「セッション開始プロトコル(一口)の暫定的な応答の信頼性」、RFC3262、2002年6月。
[RFC3265] Roach, A.B., "Session Initiation Protocol (SIP)-Specific
Event Notification", RFC 3265, June 2002.
[RFC3265]ローチ、A.B.、「セッション開始プロトコル(一口)特定のイベント通知」、RFC3265、2002年6月。
[RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP)
UPDATE Method", RFC 3311, October 2002.
[RFC3311] ローゼンバーグ、J.、「セッション開始プロトコル(一口)アップデートメソッド」、RFC3311、2002年10月。
[RFC3420] Sparks, R., "Internet Media Type message/sipfrag", RFC
3420, November 2002.
[RFC3420]はR.、「インターネットメディアTypeメッセージ/sipfrag」、RFC3420 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、「インスタントメッセージングのためのセッション開始プロトコル(一口)拡大」、RFC3428(2002年12月)。
[RFC4411] Polk, J., "Extending the Session Initiation Protocol (SIP)
Reason Header for Preemption Events", RFC 4411, February
2006.
[RFC4411] ポーク、J.、「先取り出来事のためにセッション開始プロトコル(一口)理由ヘッダーを広げています」、RFC4411、2006年2月。
Schulzrinne & Polk Standards Track [Page 33] RFC 4412 SIP Resource Priority February 2006
Schulzrinneとポーク標準化過程[33ページ]RFC4412はリソース優先権2006年2月にちびちび飲みます。
14.2. Informative References
14.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認証:」 「基本的、そして、ダイジェストアクセス認証」、RFC2617、1999年6月。
[RFC2976] Donovan, S., "The SIP INFO Method", RFC 2976, October
2000.
[RFC2976] ドノヴァン、S.、「一口インフォメーション方法」、RFC2976、2000年10月。
[RFC3323] Peterson, J., "A Privacy Mechanism for the Session
Initiation Protocol (SIP)", RFC 3323, November 2002.
[RFC3323] ピーターソン、J.、「セッション開始プロトコル(一口)のためのプライバシーメカニズム」、RFC3323、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] ジョニングス、C.、ピーターソン、J.、およびM.ワトソン、「セッション開始への個人的な拡大は断言されたアイデンティティのために信じられたネットワークの中で(一口)について議定書の中で述べます」、RFC3325、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.ローゼンは「セッション開始プロトコル(一口)のために過程を変えます」、BCP67、RFC3427、2002年12月。
[RFC3487] Schulzrinne, H., "Requirements for Resource Priority
Mechanisms for the Session Initiation Protocol (SIP)", RFC
3487, February 2003.
[RFC3487] Schulzrinne、H.、「セッション開始プロトコル(一口)のためのリソース優先権メカニズムのための要件」、RFC3487、2003年2月。
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer
Method", RFC 3515, April 2003.
[RFC3515] スパークス、R.、「セッション開始プロトコル(一口)は方法を参照する」RFC3515、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.、ニストロム、M.、Hopwood(D.、ミッケルセン、J.、およびT.ライト)は「層のセキュリティ(TLS)拡大を輸送します」、RFC3546、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:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、STD64、RFC3550、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.夏、「セッション開始プロトコル(一口)基本的な呼び出し流れの例」、BCP75、RFC3665、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メッセージ仕様」、RFC3851、2004年7月。
[RFC3893] Peterson, J., "Session Initiation Protocol (SIP)
Authenticated Identity Body (AIB) Format", RFC 3893,
September 2004.
[RFC3893] ピーターソン、J.、「セッション開始プロトコル(一口)はアイデンティティ本体(AIB)形式を認証した」RFC3893、2004年9月。
Schulzrinne & Polk Standards Track [Page 34] RFC 4412 SIP Resource Priority February 2006
Schulzrinneとポーク標準化過程[34ページ]RFC4412はリソース優先権2006年2月にちびちび飲みます。
[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年の「[RFC3903]Niemi、A.、「イベント州政府出版物のためのセッション開始プロトコル(一口)拡大」、RFC3903、イベント州政府出版物のための10月2004」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月)で働いています。
Authors' Addresses
作者のアドレス
Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 US
Buildingニューヨーク、コンピュータサイエンス450コンピュータサイエンスニューヨーク10027米国のヘニングSchulzrinneコロンビア大学部
Phone: +1 212 939 7004 EMail: hgs@cs.columbia.edu URI: http://www.cs.columbia.edu
以下に電話をしてください。 +1 7004年の212 939メール: hgs@cs.columbia.edu ユリ: http://www.cs.columbia.edu
James Polk Cisco Systems 2200 East President George Bush Turnpike Richardson, TX 75082 US
ジェイムズ・ポークシスコシステムズ2200の東社長のジョージ・ブッシュ・Turnpikeテキサス75082リチャードソン(米国)
EMail: jmpolk@cisco.com
メール: jmpolk@cisco.com
Schulzrinne & Polk Standards Track [Page 35] RFC 4412 SIP Resource Priority February 2006
Schulzrinneとポーク標準化過程[35ページ]RFC4412はリソース優先権2006年2月にちびちび飲みます。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Schulzrinne & Polk Standards Track [Page 36]
Schulzrinneとポーク標準化過程[36ページ]
一覧
スポンサーリンク
