[要約] RFC 4411は、SIP Reasonヘッダーを拡張してプリエンプションイベントをサポートするためのものです。目的は、SIPセッションの優先度を制御し、通信の品質や効率を向上させることです。
Network Working Group J. Polk
Request for Comments: 4411 Cisco Systems
Category: Standards Track February 2006
Extending the Session Initiation Protocol (SIP) Reason Header for Preemption Events
セッション開始プロトコル（SIP）の先行イベントの理由ヘッダーを拡張する
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
Abstract
概要
This document proposes an IANA Registration extension to the Session Initiation Protocol (SIP) Reason Header to be included in a BYE Method Request as a result of a session preemption event, either at a user agent (UA), or somewhere in the network involving a reservation-based protocol such as the Resource ReSerVation Protocol (RSVP) or Next Steps in Signaling (NSIS). This document does not attempt to address routers failing in the packet path; instead, it addresses a deliberate tear down of a flow between UAs, and informs the terminated UA(s) with an indication of what occurred.
このドキュメントでは、セッション開始プロトコル（SIP）のIANA登録延長を提案します。これは、ユーザーエージェント（UA）またはネットワーク内のどこかで、セッション先制イベントの結果として、BYEメソッドリクエストに含まれる理由ヘッダーを提案します。リソース予約プロトコル（RSVP）またはシグナル伝達の次のステップ（NSIS）などの予約ベースのプロトコル。このドキュメントは、パケットパスで失敗したルーターに対処しようとはしません。代わりに、UAS間の流れの意図的な解体に対処し、発生したことを示して終了したUAに通知します。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................4
2. Access Preemption Events ........................................4
2.1. Effects of Preemption at the User Agent ....................6
2.2. Reason Header Requirements for Access Preemption Events ....6
3. Network Preemption Events .......................................7
3.1. Reason Header Requirements for Network Preemption Events ..10
4. Including a Hybrid Infrastructure ..............................10
4.1. Hybrid Infrastructure Requirements ........................11
5. Preemption Reason Header Cause Codes and Semantics .............11
5.1. Access Preemption Event Reason Code .......................12
5.1.1. Access Preemption Event Call Flow ..................12
5.2. Network Preemption Events Reason Code .....................14
5.2.1. Network Preemption Event Call Flow .................15
5.3. Generic Preemption Event Reason Code ......................16
5.4. Non-IP Preemption Event Reason Code .......................16
5.4.1. Non-IP Preemption Event Call Flow ..................17
6. Security Considerations ........................................17
7. IANA Considerations ............................................17
7.1. "Preemption" Namespace Registry ...........................18
7.2. Default Reason-Text IANA Registry for the SIP
Reason Header .............................................20
8. Contributions ..................................................20
9. Acknowledgements ...............................................20
10. References ....................................................21
10.1. Normative References .....................................21
10.2. Informative References ...................................21
With the introduction of the SIP Resource-Priority (R-P) header [4], there became the possibility of sessions being torn down for (scarce) resource reasons, meaning there weren't enough resources for a particular session to continue. Certain domains will implement this mechanism where resources may become constrained either at the user agent (UA) or at congested router interfaces where more important sessions are to be completed at the expense of less important sessions. Which sessions are more or less important than others will not be discussed here. What is proposed here is a SIP [2] extension to synchronize SIP elements as to why a preemption event occurred and which type of preemption event occurred, as viewed by the element that performed the preemption of a session.
SIPリソース優先度（R-P）ヘッダー[4]の導入により、セッションが（希少な）リソース上の理由で取り壊される可能性がありました。つまり、特定のセッションが継続するのに十分なリソースがなかったことを意味します。特定のドメインは、ユーザーエージェント（UA）または混雑したルーターインターフェイスのいずれかでリソースが制約される可能性があるこのメカニズムを実装します。ここでは、他のセッションが他のセッションよりも多かれ少なかれ重要なセッションがあります。ここで提案されているのは、セッションの先制を実行した要素によって見られるように、先制イベントが発生した理由とどのタイプの先制イベントが発生したかについて、SIP要素を同期するためのSIP [2]拡張です。
The SIP Reason Header is an application layer feedback mechanism to synchronize SIP elements of events; the particular event explained here deals with preemption of a session. Q.850 [5] provides an indication for preemption (cause=8) and for preemption "circuit reserved for reuse" (cause=9). Q.850 Cause=9 does not apply to IP, as IP has no concept of circuits. Some domains wish to differentiate appropriate IP reasons for preemption of sessions and to indicate topologically where the preemption event occurred. No other means exists today to give feedback as to why a session was torn down on preemption grounds.
SIP理由ヘッダーは、イベントのSIP要素を同期するためのアプリケーションレイヤーフィードバックメカニズムです。ここで説明されている特定のイベントは、セッションの先制を扱っています。Q.850 [5]は、先制（原因= 8）と、再利用のために予約されている回路」（原因= 9）の兆候を提供します。Q.850原因= 9はIPには適用されません。IPには回路の概念がないためです。一部のドメインは、セッションの先制の適切なIP理由を区別し、先制イベントが発生した場所でトポロジカルに示すことを望んでいます。セッションが先制の場で取り壊された理由についてフィードバックを与えるために、今日、他の手段は存在しません。
In the event that a session is terminated for a specific reason that can (or should) be shared with SIP Servers and UAs sharing dialog, the Reason Header [1] was created to be included in the BYE Request. This was not the only Method for this new Header; [1] also discusses the CANCEL Method usage.
SIPサーバーとUAS共有ダイアログと共有できる特定の理由でセッションが終了した場合、BYEリクエストに含まれる理由ヘッダー[1]が作成されました。これがこの新しいヘッダーの唯一の方法ではありませんでした。[1]は、キャンセルメソッドの使用についても説明します。
This document will define two use cases in which new preemption Reason values are necessary:
このドキュメントでは、新しい先制理由値が必要な2つのユースケースを定義します。
Access Preemption Event - This is when a UA receives a new SIP session request message with a valid R-P value that is higher than the one associated with the currently active session at that UA. The UA must discontinue the existing session in order to accept the new one (according to local policy of some domains).
アクセスプリエンプションイベント - これは、UAがそのUAで現在アクティブなセッションに関連付けられたものよりも高い有効なR -P値を持つ新しいSIPセッション要求メッセージを受信する場合です。UAは、新しいセッションを受け入れるために既存のセッションを中止する必要があります（一部のドメインのローカルポリシーに従って）。
Network Preemption Event - This is when a network element - such as a router - reaches capacity on a particular interface and has the ability to statefully choose which session(s) will remain active when a new session/reservation is signaled for under the parameters outlined in SIP Preconditions per [3] that would otherwise overload that interface (perhaps adversely affecting all sessions). In this case, the router must terminate one or more reservations of lower priority in order to allow this higher priority reservation access to the requested amount of bandwidth (according to local policy of some domains).
ネットワークプリエンプションイベント - これは、ルーターなどのネットワーク要素が特定のインターフェイスの容量に達するときであり、概説されたパラメーターの下で新しいセッション/予約が信号を送信された場合、どのセッションをアクティブに保つ能力を選択する機能を備えていますそれ以外の場合はそのインターフェイスを過負荷にする[3]あたりのSIP前処理で（おそらくすべてのセッションに悪影響を及ぼします）。この場合、ルーターは、要求された量の帯域幅へのこのより高い優先予約アクセスを可能にするために、より低い優先度の1つ以上の予約を終了する必要があります（一部のドメインのローカルポリシーに従って）。
This document will cover the semantics for these two cases and request IANA registration of the new protocol value "Preemption" for the Reason Header field, with 4 cause values for the above preemption conditions. Additionally, this document will create a new IANA Registry for reason-text strings that are not currently defined through existing SIP Response codes or Q.850 cause codes. This new Registry will be useful for future protocols used by the SIP Reason header.
このドキュメントでは、これら2つのケースのセマンティクスをカバーし、理由のヘッダーフィールドの新しいプロトコル値「先制」のIANA登録を要求し、上記の先制条件の4つの原因値を使用します。さらに、このドキュメントは、既存のSIP応答コードまたはQ.850原因コードで現在定義されていない理由テキスト文字列の新しいIANAレジストリを作成します。この新しいレジストリは、SIP理由ヘッダーで使用される将来のプロトコルに役立ちます。
This document will emphasize an existing SIP RFC [3] as the starting point for network preemption events. RFC 3312 set rules surrounding SIP interaction using a reservation protocol for QoS preconditions, using RSVP as the example protocol. That effort did not preclude other preconditions or future protocol work from becoming a means of preconditions. NSIS is a new reservation protocol effort that specifies a preemption operation similar to RSVP's ResvErr message involving the NSIS NOTIFY message in [8] with a Transient error code 0x04000005 (Resources Pre-empted).
このドキュメントでは、既存のSIP RFC [3]をネットワークプリエンプションイベントの開始点として強調します。RFC 3312 SIP相互作用を取り巻くルールを設定し、QOS前条件の予約プロトコルを使用して、RSVPを例として使用します。その努力は、他の前提条件や将来のプロトコル作業が前提条件の手段になることを妨げませんでした。NSISは、過渡エラーコード0x04000005（リソースプリエンプト）を使用して[8]のNSIS通知メッセージを含むRSVPのResverrメッセージと同様の先制操作を指定する新しい予約プロトコルの取り組みです。
Note that SIP itself does not cause RSVP or NSIS reservation signaling to start or end. That operation is part of a separate API within each UA.
SIP自体は、RSVPまたはNSIS予約シグナリングを開始または終了させないことに注意してください。その操作は、各UA内の個別のAPIの一部です。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [6].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[6]で説明されているように解釈される。
As mentioned previously, Access Preemption Events (APE) occur at the user agent. It does not matter which UA in a unicast or multicast session this happens to (the UAC or UAS of a session). If local policy dictates in a particular domain rules regarding the functionality of a UA, there must be a means by which that UA (not the user) informs the other UA(s) why a session was just torn down prematurely. The appropriate mechanism is the BYE Method. The user of the other far side UA will not understand why that session "just went away" without there being a means of informing the UA of what occurred (if this event was purposeful). Through this type of indication to the preempted UA, it can indicate to the user of that device appropriately.
前述のように、ユーザーエージェントでアクセスプリエンプションイベント（APE）が発生します。これが起こるユニキャストまたはマルチキャストセッションのどのUA（セッションのUACまたはUAS）は関係ありません。UAの機能に関する特定のドメインルールでローカルポリシーが指示している場合、UA（ユーザーではない）が他のUAに、セッションが時期尚早に引き裂かれた理由を他のUAに通知する手段がなければなりません。適切なメカニズムはさようならメソッドです。もう一方のFarsid UAのユーザーは、UAに何が起こったかを知らせる手段がなければ、そのセッションが「ちょうど去った」理由を理解しません（このイベントが意図的であった場合）。このタイプの先制uaへの兆候により、そのデバイスのユーザーに適切に示すことができます。
The rules within a domain surrounding the UA to be informed can be different from the rules for informing the user. Local policy should determine if the user should be informed of the specific reason. This indication in SIP will provide a means for the UA to react in a locally determined way, if appropriate (play a certain tone or tone sequence, point towards a special announcement uri, cause the UA's visual display to do something, etc.).
通知されるUAを取り巻くドメイン内のルールは、ユーザーに通知するためのルールとは異なる場合があります。ローカルポリシーは、ユーザーに特定の理由を通知する必要があるかどうかを判断する必要があります。SIPでのこの表示は、UAが必要に応じて局所的に決定された方法で反応する手段を提供します（特定のトーンまたはトーンシーケンスを再生し、特別な発表URIを指し、UAの視覚ディスプレイに何かを行うなど）。
Figure 1 illustrates the scenario. UA1 invites UA2 to a session with the Resource Priority level of 3 (levels 1 and 2 are higher is this domain, and the namespace element is not necessary for this discussion).
図1は、シナリオを示しています。UA1はUA2を3のリソース優先レベルでセッションに招待します（レベル1と2はこのドメインが高く、この議論には名前空間要素は必要ありません）。
UA1 UA2 UA3
| | |
| INVITE (R-P:3) | |
|----------------------->| |
| 200 OK | |
|<-----------------------| |
| ACK | |
|----------------------->| |
| RTP | |
|<======================>| |
| | INVITE (R-P:2) |
| |<------------------------|
| BYE (Reason : ? ) | |
|<-----------------------| |
| | 200 OK |
| |------------------------>|
| 200 OK | |
|----------------------->| |
| | ACK |
| |<------------------------|
| | RTP |
| |<=======================>|
| | |
Figure 1. Access Preemption with obscure Reason
図1.あいまいな理由でのアクセスプリエンプション
After the session between UA1 and UA2 is established, UA3 invites UA2 to a new session with an R-P of 2 (a higher priority than the current session between UA1 and UA2). Local policy within this domain dictates that UA2 must preempt all existing calls of lower priority in order to accept a higher priority call.
UA1とUA2の間のセッションが確立された後、UA3はUA2を2のR-Pで新しいセッションに招待します（UA1とUA2の間の現在のセッションよりも優先度が高い）。このドメイン内のローカルポリシーは、UA2が優先度の高い呼び出しを受け入れるために、より低い優先度のあるすべての既存の呼び出しを先取りする必要があることを規定しています。
What Reason value could be inserted above to mean "preemption" at a UA? There are several choices: 410 "Gone", 480 "Temporarily Unavailable", 486 "Busy Here", and 503 "Service Unavailable". The use of any of these here is questionable because the session is already established. It is further complicated if there needs to be a difference in the Reason value for an Access versus a Network Preemption Event (which is a requirement here). The limits of Q.850 [5] have been stated previously in this document.
UAでの「先制」を意味するために、上に挿入できる理由は何ですか？いくつかの選択肢があります：410「GONE」、480「一時的に利用できない」、486「ここでは忙しい」、503「サービスは利用できません」。ここでこれらのいずれかの使用は、セッションがすでに確立されているため、疑わしいです。アクセスの理由とネットワークの先制イベントの理由に違いがある必要がある場合、さらに複雑です（ここでは要件です）。Q.850 [5]の制限は、この文書に以前に記載されています。
It should be possible to configure UAs receiving a preemption indication to indicate to the user that no particular type of preemption occurred. There are some domains that might prefer their users to remain unaware of the specifics of network behavior. This should not ever prevent a known preemption indication from being sent in a BYE from a UA.
特定のタイプの先制が発生していないことをユーザーに示すように、先制指示を受信するUASを構成することが可能です。ユーザーがネットワーク動作の詳細に気付いていないことを好む可能性のあるドメインがいくつかあります。これは、既知の先制兆候がUAからさようならで送信されるのを防ぐべきではありません。
If 2 UAs are in a session and one UA must preempt that session to accept another session, a BYE Method message is the appropriate mechanism to perform this task. However, taking this a step further, if a UA is the common point of a 3-way (or more) ad hoc conference and must preempt all sessions in that conference due to receipt of a higher-priority session request (that this UA must accept), then a BYE message must be sent to all UAs in that ad hoc conference.
2つのUAがセッションにあり、1つのUAが別のセッションを受け入れるためにそのセッションを先取りする必要がある場合、BYEメソッドメッセージはこのタスクを実行するための適切なメカニズムです。ただし、UAが3ウェイ（またはそれ以上の）アドホック会議の共通点であり、より優先順位のセッションリクエストの受領によりその会議のすべてのセッションを先取りしなければならない場合、これをさらに一歩進めることができます（このUAはそうする必要があります受け入れる）、その後、そのアドホック会議のすべてのUASにさようならメッセージを送信する必要があります。
The following is a list of requirements for adding an appropriate Reason value for an Access Preemption Event (APE) as described above and shown in Figure 1:
以下は、上記のように、図1に示すように、アクセス先制イベント（APE）に適切な理由値を追加するための要件のリストです。
APE_REQ#1 - create a means by which one UA can inform another UA (within the same active session) that the active session between the two devices is being purposely preempted at one UA for a higher-priority session request from another UA.
APE_REQ＃1- 1つのUAが別のUA（同じアクティブセッション内）に、2つのデバイス間のアクティブなセッションが、別のUAからの優先順位セッションリクエストのために意図的に1つのUAで先取りされていることを通知できる手段を作成します。
APE_REQ#2 - create a means by which all relevant SIP elements can be informed of this Access Preemption Event to a specific session.
APE_REQ＃2-関連するすべてのSIP要素に、特定のセッションのこのアクセス先制イベントを通知できる手段を作成します。
For example: perhaps SIP Servers that have incorporated a Record-Route header into that session set up need to be informed of this occurrence.
例：おそらく、記録的なヘッダーをそのセッションに組み込んだSIPサーバーは、この発生を通知する必要があります。
APE_REQ#3 - create a means of informing all participants in an ad hoc conference that the primary UA (the mixer) has preempted the conference by accepting a higher-priority session request.
APE_REQ＃3-アドホックカンファレンスのすべての参加者に、プライマリUA（ミキサー）がより優先順位セッションリクエストを受け入れることにより会議を先取りしたことを通知する手段を作成します。
APE_REQ#4 - create a separate indication for the access preemption event than the one used for a Network Preemption Event (described in the next section) in the session BYE message.
APE_REQ＃4-セッションBYEメッセージのネットワークプリエンプションイベント（次のセクションで説明）に使用されているものよりも、アクセスプリエンプションイベントの個別の表示を作成します。
APE_REQ#5 - create a means to generate a specific indication of a preemption event at the user agent to inform all relevant SIP entities, yet have the ability to generalize this indication (based on local policy) to the receiving UA such that this UA cannot display more information than the domain wants the user to see.
APE_REQ＃5-ユーザーエージェントでの先制イベントの特定の表示を生成する手段を作成して、関連するすべてのSIPエンティティに通知することができますが、このuaが受信する（ローカルポリシーに基づいて）この兆候を一般化する能力があるため、このUAができません。ドメインがユーザーに表示したいよりも多くの情報を表示します。
Network Preemption Events (NPE) are instances in which an intermediate router between SIP user agents preempts one or more sessions at one of its interfaces to place a higher-priority session through that interface. Within RSVP, there exists a means to execute this functionality per [7]: ResvErr messages, which travel downstream towards appropriate receivers. The ResvErr message has the ability to carry within it a code indicating why a reservation is being torn down. The ResvErr does not travel upstream to the other UA. This document proposes that a SIP message be generated to synchronize all relevant SIP elements to this preemption event, including the upstream UA. Creating another Reason value describing that a network element preempted the session is necessary in certain domains.
ネットワークプリエンプションイベント（NPE）は、SIPユーザーエージェント間の中間ルーターがそのインターフェイスの1つで1つ以上のセッションを先取りし、そのインターフェイスを通してより優先順位セッションを配置するインスタンスです。RSVP内には、[7]に従ってこの機能を実行する手段が存在します。これは、適切なレシーバーに向かって下流に移動します。RESVERRメッセージには、予約が取り壊されている理由を示すコードを内部に携帯する機能があります。Resverrは他のUAに上流に移動しません。このドキュメントは、上流のUAを含むこの先制イベントに関連するすべてのSIP要素を同期するために、SIPメッセージを生成することを提案しています。特定のドメインでセッションを先取りしたネットワーク要素が必要であることを説明する別の理由を作成します。
Figures 2 and 3 illustrate a network preemption scenario with RSVP. NSIS, not shown in examples here, can be imagined from [8] with a NOTIFY error message indicating that a reservation has been preempted with the Transient ERROR_SPEC 0x04000005. SIP behavior will be identical using either reservation protocol.
図2と3は、RSVPのネットワーク先制シナリオを示しています。NSIは、ここの例には示されていませんが、[8]から想像することができますが、通知エラーメッセージを使用して、一時的なerror_spec 0x04000005で予約が先取りされていることを示しています。SIPの動作は、いずれかの予約プロトコルを使用して同一になります。
UA1 invites UA2 to a session with the Resource Priority level of 3 (levels 1 and 2 are higher in this domain) and is accepted. This SIP signaling translated the Resource Priority value to an appropriate RSVP priority level for that flow. The link between Router 1 and Router 2 became saturated with this session reservation between UA1 and UA2 (in this example).
UA1はUA2を3のリソース優先レベルでセッションに招待します（このドメインではレベル1と2は高くなります）。このSIPシグナリングは、リソースの優先順位値をそのフローの適切なRSVP優先レベルに変換しました。Router 1とRouter 2の間のリンクは、UA1とUA2の間のこのセッション予約により飽和状態になりました（この例で）。
UA1 UA2
\ /
\ /
+--------+ +--------+
| | | |
| RTR1 | | RTR2 |
| Int7-------Int5 |
| | | |
+--------+ +--------+
/ \
/ \
UA3 UA4
Figure 2. Network Diagram Scenario A
図2.ネットワーク図シナリオa
After the session between UA1 and UA2 is established, UA3 invites UA4 to a new session with a Resource Priority level of 2 (a higher priority than the current reservation between UA1 and UA2). Again, the priority value within the Resource-Priority header of this INVITE is translated into an appropriate RSVP priority (that is also higher in relative priority to the UA1_UA2 session/RSVP flow). When this second, higher-priority session is signaled, one Path message goes from UA3 to UA4, resulting in the RESV message going from UA4 back to UA3. Because this link between the two routers is at capacity (at Int7 in Figure 5), Router 1 will (in this example) make the decision or will communicate with another network entity that will make the decision to preempt lower-priority BW to ensure that this higher-priority session reservation is completed. A ResvErr message is sent to UA2. The result is that UA2 will know that there has been a preemption event in a router (because the ResvErr message has a error code within it, stating "preemption"). At this point, UA1 will not know anything of this preemption. If there are any SIP Proxies between UAs 1 and 2 (perhaps that inserted a Record-Route Header), each will also need to be informed as to why this reservation was torn down.
UA1とUA2の間のセッションが確立された後、UA3はUA4を2のリソース優先レベルで新しいセッションに招待します（UA1とUA2の間の現在の予約よりも優先度が高い）。繰り返しますが、この招待のリソース優先ヘッダー内の優先値は、適切なRSVP優先度に変換されます（これは、UA1_UA2セッション/RSVPフローの相対的な優先度も高くなっています）。この秒、より優先順位セッションが信号を送ると、1つのパスメッセージがUA3からUA4になり、UA4からUA3に戻るRESVメッセージが表示されます。2つのルーター間のこのリンクは容量（図5のINT7）にあるため、ルーター1は（この例で）決定を下すか、より低優先度のBWを先制する決定を下す別のネットワークエンティティと通信します。この優先順位セッションの予約は完了しました。ResverrメッセージがUA2に送信されます。その結果、UA2はルーターにプリエンプションイベントがあったことを知っています（Resverrメッセージには「先制」と記載されているエラーコードがあるため）。この時点で、UA1はこの先制について何も知りません。UAS 1と2の間にSIPプロキシがある場合（おそらくレコードルートヘッダーを挿入した場合）、それぞれがこの予約が取り壊された理由についても通知する必要があります。
Figure 3 shows the call flow with Router 2 from Figure 2 included at the RSVP layer sending the ResvErr message. A complete call flow including all UAs and Routers is not shown here for diagram complexity reasons. The complete signaling between UA3 and UA4 is also not included.
図3は、RSVPレイヤーに含まれる図2のRouter 2を使用したコールフローを、Resverrメッセージを送信します。すべてのUASおよびルーターを含む完全なコールフローは、図の複雑さの理由でここには表示されません。UA3とUA4の間の完全な信号も含まれていません。
UA1 Rtr2 UA2
| | |
| INVITE with QoS Preconditions (R-P:3) |
|------------------------------------------------->|
| ******************************************** |
| * - QoS Preconditions established UA1-UA2 * |
| * - SIP signaling continues... * |
| ******************************************** |
| 200 OK |
|<-------------------------------------------------|
| ACK |
|------------------------------------------------->|
| RTP |
|<================================================>|
| ******************************************** |
| * -UA3 sends INV with QoS Preconditions * |
| * to UA4 w/ RP:2; * |
| * -Reservation set-up occurs between UA3 * |
| * and UA4 * |
| * -Router 2 in Figure 2 must preempt * |
| * reservation between UA1 & UA2 * |
| * ****************************************** |
| |
| | ResvErr |
| |------------------------>|
| | |
| |
| BYE (Reason : ? ) |
|<-------------------------------------------------|
| 200 OK |
|------------------------------------------------->|
| |
Figure 3. Network Preemption with obscure Reason
図3.あいまいな理由を伴うネットワークプリエンプション
What Reason value could be inserted above to mean "preemption at a router interface"? There are several choices: 410 "Gone", 480 "Temporarily Unavailable", 486 "Busy Here", and 503 "Service Unavailable". The use of any of these here is questionable because the session is already established. It is further complicated if there needs to be a difference between the Reason value for an Access Preemption Event versus a Network Preemption Event. The limits of Q.850 [5] have already been stated previously, showing there is nothing in that spec to indicate a problem in an IP network.
「ルーターインターフェイスでの先制」を意味するために、上に挿入できる理由は何ですか？いくつかの選択肢があります：410「GONE」、480「一時的に利用できない」、486「ここでは忙しい」、503「サービスは利用できません」。ここでこれらのいずれかの使用は、セッションがすでに確立されているため、疑わしいです。Access Preemptionイベントの理由とネットワークプリエンプションイベントの違いが必要な場合、さらに複雑です。Q.850 [5]の制限はすでに以前に記載されており、IPネットワークで問題を示すためにその仕様には何もないことを示しています。
To state that all preemptions are equal is possible, but will not provide adequate information. Therefore, another Reason Header value is necessary to differentiate the APE from the NPE.
すべての先制が平等であると述べることは可能ですが、適切な情報を提供しません。したがって、類人猿をNPEと区別するためにヘッダー値が必要です。
The following are the requirements for the appropriate SIP signaling in reaction to a Network Preemption Event (NPE):
以下は、ネットワーク先制イベント（NPE）に反応する適切なSIPシグナリングの要件です。
NPE_REQ#1 - create a means of informing the far-end UA that a Network Preemption Event has occurred in an intermediate router.
NPE_REQ＃1 -FAREND UAに、ネットワーク先制イベントが中間ルーターで発生したことを通知する手段を作成します。
NPE_REQ#2 - create a means by which all relevant SIP elements can be informed of a Network Preemption Event to a specific session.
NPE_REQ＃2-関連するすべてのSIP要素に、特定のセッションのネットワークプリエンプションイベントを通知できる手段を作成します。
For example: perhaps SIP Servers have incorporated a Record-Route header into that session set up.
例：おそらく、SIPサーバーがレコードルートヘッダーをそのセッションのセットアップに組み込んでいます。
NPE_REQ#3 - create a means of informing all participants in an ad hoc conference that the primary UA (the mixer) has been preempted by a Network Preemption Event.
NPE_REQ＃3-アドホックカンファレンスのすべての参加者に、プライマリUA（ミキサー）がネットワークプリエンプションイベントによって先取りされていることを通知する手段を作成します。
NPE_REQ#4 - create a separate description of the Network Preemption Event relative to an Access Preemption Event in SIP.
NPE_REQ＃4-SIPのアクセス先イベントと比較して、ネットワークプリエンプションイベントの別の説明を作成します。
If User 1 is in a non-IP portion of infrastructure (using a TDM phone) in a session with a UA through a SIP gateway, and if the TDM portion had the ability to preempt the session and indicate to the SIP gateway when it did such a preemption, the SIP GW would need to be able to convey this preemption event into the SIP portion of this session just as if User 1 were a UA in the session. Below is a diagram of this:
ユーザー1がSIPゲートウェイを介してUAとのセッションでインフラストラクチャの非IP部分（TDM電話を使用）にあり、TDM部分がセッションを先取りし、SIPゲートウェイに示す機能がある場合このような先制では、SIP GWは、この先制イベントを、ユーザー1がセッションでUAであるかのように、このセッションのSIP部分に伝えることができる必要があります。以下はこれの図です。
**************************
* TDM network *
* +---------+
* User 1 | |
* O ==========>| SIP GW1 |================> UA2
* /|\ ^ | | |
* / \ | +---------+ |
* | * |
**********|*************** | |
| | Preemption |
Preemption ---------> |--------------------->|
Event Indication
Figure 4. TDM/IP Preemption Event
図4. TDM/IP先制イベント
The following are the requirements unique to the topology involving both IP infrastructure and TDM (or non-IP) infrastructure.
以下は、IPインフラストラクチャとTDM（または非IP）インフラストラクチャの両方を含むトポロジに固有の要件です。
HYB_REQ#1 - create a means of informing the far-end UA in a dialog through a SIP gateway with a non-IP phone that the TDM portion of the session indicated to the SIP gateway that a preemption event terminated the session.
hyb_req＃1-セッションのTDM部分がSIPゲートウェイにプリエンプションイベントがセッションを終了したことを示す非IP電話を使用して、SIPゲートウェイを介したダイアログでファーエンドUAに通知する手段を作成します。
HYB_REQ#2 - create a means of identifying this preemption event uniquely with respect to an access preemption and network preemption event.
hyb_req＃2-アクセスの先制およびネットワークプリエンプションイベントに関して、この先制イベントを一意に識別する手段を作成します。
This document defines the following new protocol value for the protocol field of the Reason header field in RFC 3326 [1]:
このドキュメントは、RFC 3326 [1]の理由ヘッダーフィールドのプロトコルフィールドの次の新しいプロトコル値を定義します。
Preemption: The cause parameter contains a preemption cause code.
プリエンプション：原因パラメーターには、プリエンプション原因コードが含まれています。
We define the following preemption cause codes:
次の先制の原因コードを定義します。
Value Default Text Description
値デフォルトのテキストの説明
1 UA Preemption The session has been preempted by a UA.
1 UA先制セッションはUAによって先取りされています。
2 Reserved Resources The session preemption has been Preempted initiated within the network via a purposeful RSVP preemption occurrence, and not a link error.
2予約されたリソースセッションの先制は、リンクエラーではなく、目的のあるRSVPプリエンプション発生を介してネットワーク内で開始されました。
3 Generic Preemption This is a limited-use preemption indication to be used on the final leg to the preempted UA to generalize the event.
3ジェネリック先制これは、イベントを一般化するために最終脚で使用される最終脚で使用される限定使用先の指示です。
4 Non-IP Preemption The session preemption has occurred in a non-IP portion of the infrastructure, and this is the Reason cause code given by the SIP Gateway.
4非私の先制セッションの先制は、インフラストラクチャの非IP部分で発生しました。これが、SIPゲートウェイで与えられたコードの理由です。
Example syntax for the above preemption types are as follows:
上記の先制型の例の例は次のとおりです。
Reason: preemption ;cause=1 ;text="UA Preemption"
Reason: preemption ;cause=2 ;text="Reserved Resources Preempted"
Reason: preemption ;cause=3 ;text="Generic Preemption"
Reason: preemption ;cause=4 ;text="Non-IP Preemption"
Sections 5.1, 5.2, 5.3, and 5.4 provide use cases and extended definitions for the above four cause codes with message flow diagrams.
セクション5.1、5.2、5.3、および5.4は、メッセージフロー図を備えた上記の4つの原因コードのユースケースと拡張定義を提供します。
A more elaborate description of the Access Preemption Event cause=1 is as follows:
アクセスプリエンプションイベントの原因= 1のより精巧な説明は次のとおりです。
A user agent in a session has purposely preempted a session and is informing the far-end user agent, or user agents (if part of a conference), and SIP Proxies (if stateful of the session's transactions)
セッションのユーザーエージェントは、意図的にセッションを先取りし、ファーエンドのユーザーエージェントまたはユーザーエージェント（会議の一部の場合）に通知し、SIPプロキシ（セッションのトランザクションの状態の場合）に通知しています
An example usage of this header value would be:
このヘッダー値の使用例は次のとおりです。
Reason: preemption ;cause=1 ;text="UA Preemption"
Figure 5 replicates the call flow from Figure 1, but with an appropriate Reason value indication that was proposed in Section 4.1, above:
図5は、図1からのコールフローを複製しますが、上記のセクション4.1で提案されている適切な理由の表示があります。
UA1 UA2 UA3
| | |
| INVITE (R-P:3) | |
|---------------------------------->| |
| 200 OK | |
|<----------------------------------| |
| ACK | |
|---------------------------------->| |
| RTP | |
|<=================================>| |
| | INVITE (R-P:2) |
| |<-------------------|
| BYE (Reason: Preemption ; | |
| cause=1 ;text="UA Preemption") | |
|<----------------------------------| |
| | 200 OK |
| |------------------->|
| 200 OK | |
|---------------------------------->| |
| | ACK |
| |<-------------------|
| | RTP |
| |<==================>|
| | |
Figure 5. Access Preemption with Reason: UA Preemption
図5.理由を伴うアクセスプリエンプション：UAプリエンプション
UA1 invites UA2 to a session with the Resource Priority level of 3 (levels 1 and 2 are higher in this domain). After the session between UA1 and UA2 is established, UA3 invites UA2 to a new session with an R-P of 2 (a higher priority than the current session to UA1). Local policy within this domain dictates that UA2 must preempt all existing calls of lower priority in order to accept a higher-priority call.
UA1はUA2を3のリソース優先度レベルでセッションに招待します（このドメインではレベル1と2が高くなっています）。UA1とUA2の間のセッションが確立された後、UA3はUA2を2のR-Pで新しいセッションに招待します（UA1の現在のセッションよりも優先度が高い）。このドメイン内のローカルポリシーは、UA2がより優先順位の呼び出しを受け入れるために、より低い優先度のあるすべての既存の呼び出しを先取りする必要があることを規定しています。
UA2 sends a BYE Request message with a Reason header with a value of UA Preemption. This will inform the far-end UA (UA1) and all relevant SIP elements (for example, SIP Proxies). The cause code is unique to what is proposed in the RSVP Preemption Event for differentiation purposes.
UA2は、UA先制の値を持つ理由ヘッダーを持つBYEリクエストメッセージを送信します。これにより、ファーエンドUA（UA1）と関連するすべてのSIP要素（たとえば、SIPプロキシ）に通知されます。原因コードは、差別化のためにRSVP先制イベントで提案されているものと一意のものです。
A more elaborate description of the Reserved Resources Preempted Event cause=2 is as follows:
予約されたリソースのより精巧な説明は、事前にイベントの原因= 2が次のとおりです。
A router has preempted a reservation flow and generated a reservation error message: a ResvErr traveling downstream in RSVP, and a NOTIFY in NSIS. The UA receiving the preemption error message generates a BYE request towards the far-side UA with a Reason Header with this value indicating that somewhere between two or more UAs, a router has administratively preempted this session.
ルーターは予約フローを先取りし、RSVPの下流に移動するResverrとNSISでの通知を生成しました。プリエンプションエラーメッセージを受信するUAは、2つ以上のUASの間のどこかで、ルーターがこのセッションを管理していたことを示す、この値のヘッダーを持つファーサイドUAに対するバイ要求を生成します。
An example usage of this header value would be:
このヘッダー値の使用例は次のとおりです。
Reason: Preemption :cause=2 ;text="Reserved Resources Preempted"
Figure 6 replicates the call flow from Figure 5, but with an appropriate Reason value indication that was proposed in Section 4.2, above.
図6は、図5からのコールフローを複製しますが、上記のセクション4.2で提案された適切な理由の表示を備えています。
UA1 Rtr2 UA2
| | |
| INVITE with QoS Preconditions (R-P:3) |
|---------------------------------------------------->|
| ******************************************** |
| * - QoS Preconditions established UA1-UA2 * |
| * - SIP signaling continues... * |
| ******************************************** |
| 200 OK |
|<----------------------------------------------------|
| ACK |
|---------------------------------------------------->|
| RTP |
|<===================================================>|
| ******************************************** |
| * -UA3 sends INV with QoS Preconditions * |
| * to UA4 w/ RP:2; * |
| * -Reservation set-up occurs between UA3 * |
| * and UA4 * |
| * -Router 2 in Figure 2 must preempt * |
| * reservation between UA1 & UA2 * |
| * ********************************************* |
| |
| | ResvErr |
| |------------------------>|
| | |
| |
| BYE (Reason : Preemption ;cause=2 ; |
| text="Reserved Resources Preempted") |
|<----------------------------------------------------|
| 200 OK |
|---------------------------------------------------->|
| |
Figure 6. Network Preemption with "Reserved Resources Preempted"
図6.「予約されたリソースが先制された」とのネットワークプリエンプション
Above is the call flow with Router 2 from Figure 2 included at the RSVP layer sending the Resv messages. A complete call flow including all UAs and Routers is not included for diagram complexity reasons. The signaling between UA3 and UA4 is also not included.
上記は、RSVメッセージを送信するRSVPレイヤーに含まれる図2のルーター2を備えたコールフローです。すべてのUASおよびルーターを含む完全なコールフローは、図の複雑さの理由では含まれていません。UA3とUA4の間の信号も含まれていません。
Upon receipt of the ResvErr message with the preemption error code, UA2 can now appropriately inform UA1 why this event occurred. This BYE message will also inform all relevant SIP elements, synchronizing them. The cause value is unique to that proposed in Section 4.1 for Access Preemption Events for differentiation purposes.
Preemptionエラーコードを使用してResverrメッセージを受信すると、UA2はUA1がこのイベントが発生した理由を適切に通知できるようになりました。また、このByeメッセージは、関連するすべてのSIP要素を同期させ、同期します。原因値は、差別化の目的でアクセス前のイベントについて、セクション4.1で提案されているものと一意のものです。
A more elaborate description of the Generic Preemption Event cause=3 is as follows:
一般的な先制イベントの原因= 3のより精巧な説明は次のとおりです。
This cause code is for infrastructures that do not wish to provide the preempted UA with a more precise reason than just "preemption". It is possible that UAs will have code that will indicate the type of preemption event that is contained in the Reason header, and certain domains have expressed this as not being optimal, and wanted to generalize the indication. This MUST NOT be the initial indication within these domains, as valuable traffic analysis and other NM applications will be generalized as well. If this cause value is to be implemented, it SHOULD only be done at the final SIP Proxy in such a way that the cause value indicating which type of preemption event actually occurred is changed to this generalized preemption indication to be received by the preempted UA.
この原因コードは、先制されたUAに単なる「先制」よりも正確な理由を提供したくないインフラストラクチャ用です。UASには、理由ヘッダーに含まれる先制イベントのタイプを示すコードがあり、特定のドメインがこれを最適ではないと表現し、適応を一般化したいと考えている可能性があります。貴重なトラフィック分析や他のNMアプリケーションも一般化されるため、これはこれらのドメイン内の初期兆候であってはなりません。この原因値が実装される場合、実際に発生したタイプの先制イベントを示す原因値が、先制的なUAによって受信されるこの一般化された先制指示に変更されるように、最終SIPプロキシでのみ行う必要があります。
An example usage of this header value would be:
このヘッダー値の使用例は次のとおりです。
Reason: preemption ;cause=3 ;text="Generic Preemption"
A more elaborate description of the Non-IP Preemption Event cause=4 is as follows:
非IP先制イベントの原因= 4のより精巧な説明は次のとおりです。
A session exists in a hybrid IP/non-IP infrastructure and the preemption event occurs in the non-IP portion, and was indicated by that portion that this call termination was due to preemption. This is the indication that would be generated by a SIP Gateway towards the SIP UA that is being preempted, traversing whichever SIP Proxies are involved in session signaling (a question of server state).
セッションはハイブリッドIP/非IPインフラストラクチャに存在し、Preemptionイベントは非IP部分で発生し、その部分でこの呼び出し終了が先制によるものであることが示されました。これは、SIP UAに向かってSIPゲートウェイによって生成されることを示しています。
An example usage of this header value would be:
このヘッダー値の使用例は次のとおりです。
Reason: preemption ;cause=4 ;text="Non-IP Preemption"
Figure 7 is a simple call flow diagram of the Non-IP Preemption Event.
図7は、非IP先制イベントの単純なコールフロー図です。
............
UA1 SIP GW1 . User3 .
| | . .
| INVITE (R-P:1) | . .
|-------------------------------------->| . Non-IP .
| 200 OK | . .
|<--------------------------------------| . Network .
| ACK | . .
|-------------------------------------->| . .
| RTP | . .
|<=====================================>| . .
| | . .
| BYE (Reason: Preemption ; |<==Preemption Indication
| cause=4 ;text="Non-IP Preemption") | . .
|<--------------------------------------| . .
| | ............
Figure 7. Non-IP Preemption Flow
図7.非課税フロー
In this case, UA1 signals User3 to a session. Once established, there is a preemption event in the non-IP portion of the session/call, and the TDM portion has the ability to inform the SIP GW of this type of event. This non-IP signal can be translated into SIP signaling (into the BYE session termination message). Within this BYE, there should be a Reason header indicating such an event to synchronize all SIP elements.
この場合、UA1はuser3をセッションに信号します。一度確立されると、セッション/コールの非IP部分にプリエンプションイベントがあり、TDM部分にはこのタイプのイベントのSIP GWに通知する機能があります。この非IP信号は、SIPシグナル伝達（BYEセッション終了メッセージに）に変換できます。このさようならの中で、すべてのSIP要素を同期するようなイベントを示すヘッダーがあるはずです。
Eavesdropping on this header field should not prevent proper operation of the SIP protocol, although some domains utilizing this mechanism for notifying and synchronizing SIP elements will likely want the integrity to be assured. It is therefore RECOMMENDED that integrity protection be applied when using this header to prevent unwanted changes to the field and snooping of the messages. The accepted choices for providing integrity protection in SIP are TLS and S/MIME.
このヘッダーフィールドを盗聴することは、SIPプロトコルの適切な動作を防ぐべきではありませんが、SIP要素を通知および同期するためにこのメカニズムを利用する一部のドメインは、整合性を保証することを望んでいる可能性があります。したがって、このヘッダーを使用して、フィールドへの不要な変更とメッセージのスヌーピングを防ぐために、整合性保護を適用することをお勧めします。SIPで整合性保護を提供するための受け入れられた選択は、TLSおよびS/MIMEです。
This document adds to one existing IANA Registry and creates one new
Registry. The existing IANA Registry for the SIP Reason Header is as
follows:
Protocol Value Protocol Cause Reference
-------------- -------------- ---------
SIP Status code RFC 3261
Q.850 Cause value in decimal ITU-T Q.850
This document adds to that Registry with the following entry (including the '*' comment):
このドキュメントは、次のエントリ（「*」コメントを含む）でそのレジストリに追加されます。
Protocol Value Protocol Cause Reference
-------------- -------------- ---------
Preemption Cause value in decimal* RFC 4411
* See the separate "Preemption" Registry for default reason-text strings.
* デフォルトの理由テキスト文字列については、個別の「先制」レジストリを参照してください。
The cause values created by the Preemption Protocol namespace in this document are defined in Section 7.1. Each cause value has a Reason-text string as a general description of what the cause value is for. This is shown for the existing Reason header in Section 2 of RFC 3326. Before this document, the Reason-text was taken from the SIP Response code string from all SIP Response codes, or the default description from Q.850 cause codes. Currently, there is no place to register new reason-text strings other than from those two sources. Because this document defines a new Reason header protocol namespace, a new IANA Registry is created in Section 7.2 just for this and future Reason header protocol namespaces (other than SIP Response codes or Q.850 cause values) to register their respective general descriptive text strings. These text strings are non-binding and merely the default for human understanding, but they are deemed important enough to have their own Registry.
このドキュメントの先制プロトコル名空間によって作成された原因値は、セクション7.1で定義されています。各原因値には、原因値の目的の一般的な説明として理由テキスト文字列があります。これは、RFC 3326のセクション2の既存の理由ヘッダーについて示されています。このドキュメントの前に、理由テキストはすべてのSIP応答コードのSIP応答コード文字列から取得されました。現在、これらの2つのソース以外の新しい理由テキスト文字列を登録する場所はありません。このドキュメントは新しい理由ヘッダープロトコル名空間を定義するため、これと将来の理由ヘッダープロトコル名（SIP応答コードまたはQ.850原因値以外）のためだけに、新しいIANAレジストリがセクション7.2に作成され、それぞれの一般的な記述テキスト文字列を登録します。これらのテキスト文字列は拘束力のないものであり、単に人間の理解のためのデフォルトですが、独自のレジストリを持つのに十分なほど重要であると考えられています。
RFC 4411 creates the new SIP "Reason Header" [1] protocol namespace: "Preemption", with 4 defined cause codes:
RFC 4411は、4つの定義された原因コードを使用して、新しいSIP "Reason Header" [1] Protocol namespace： "Preemption"を作成します。
In instances where this namespace is used to indicate preemption at a UA, the following syntax shall be used (the reason-text is a default string; it is not mandatory, and may be different):
この名前空間がUAでの先制を示すために使用される場合、次の構文を使用するものとします（理由テキストはデフォルトの文字列です。必須ではなく、異なる場合があります）：
Reason: preemption ;cause=1 ;text="UA Preemption"
Section 5.1 of this document describes in detail the semantics of this cause code.
このドキュメントのセクション5.1では、この原因コードのセマンティクスについて詳しく説明しています。
The default text above is part of a new IANA Registry for default text strings for any new protocol namespace cause code. See Section 7.2 for details.
上記のデフォルトのテキストは、新しいプロトコル名の原因コードのデフォルトテキスト文字列の新しいIANAレジストリの一部です。詳細については、セクション7.2を参照してください。
In instances where this namespace is used to indicate preemption because an RSVP ResvErr message was received at a SIP UA, the following syntax shall be used (the reason-text is a default string; it is not mandatory, and may be different):
RSVP ResverrメッセージがSIP UAで受信されたためにこの名前空間が先制を示すために使用される場合、次の構文を使用するものとします（理由テキストはデフォルトの文字列です。必須ではなく、異なる場合があります）：
Reason: preemption ;cause=2 ;text="Reserved Resources Preempted"
Section 5.2 of this document describes in detail the semantics of this cause code.
このドキュメントのセクション5.2では、この原因コードのセマンティクスについて詳しく説明しています。
The default text above is part of a new IANA Registry for default text strings for any new protocol namespace cause code. See section 7.2 for details.
上記のデフォルトのテキストは、新しいプロトコル名の原因コードのデフォルトテキスト文字列の新しいIANAレジストリの一部です。詳細については、セクション7.2を参照してください。
In instances where this namespace is used to indicate a generalized preemption event to the destination UA from a Proxy that modifies the Reason value only during this last SIP hop, the following syntax shall be used (the reason-text is a default string; it is not mandatory, and may be different):
この名前空間を使用して、この最後のSIPホップ中にのみ理由値を変更するプロキシから一般化された先制イベントを宛先UAに示すために使用される場合、次の構文を使用するものとします（理由はデフォルトの文字列です。必須ではなく、異なる場合があります）：
Reason: preemption ;cause=3 ;text="Generic Preemption"
Section 5.3 of this document describes in detail the semantics of this cause code.
このドキュメントのセクション5.3では、この原因コードのセマンティクスについて詳しく説明しています。
The default text above is part of a new IANA Registry for default text strings for any new protocol namespace cause code. See Section 7.2 for details.
上記のデフォルトのテキストは、新しいプロトコル名の原因コードのデフォルトテキスト文字列の新しいIANAレジストリの一部です。詳細については、セクション7.2を参照してください。
In instances where this namespace is used to indicate preemption from a non-IP portion of a call leg, a SIP Gateway shall use the following syntax to inform the SIP infrastructure of this event (the reason-text is a default string; it is not mandatory, and may be different):
この名前空間がコールレッグの非IP部分の先制を示すために使用される場合、SIPゲートウェイは次の構文を使用して、このイベントのSIPインフラストラクチャを通知するものとします（Reason-Textはデフォルトの文字列です。必須であり、異なる場合があります）：
Reason: preemption ;cause=4 ;text=" Non-IP Preemption"
Section 5.4 of this document describes in detail the semantics of this cause code.
このドキュメントのセクション5.4では、この原因コードのセマンティクスについて詳しく説明しています。
The default text above is part of a new IANA Registry for default text strings for any new protocol namespace cause code. See Section 7.2 for details.
上記のデフォルトのテキストは、新しいプロトコル名の原因コードのデフォルトテキスト文字列の新しいIANAレジストリの一部です。詳細については、セクション7.2を参照してください。
Additional definitions of the preemption namespace and its cause codes MUST be defined in Standards Track documents.
プリエンプションネームスペースとその原因コードの追加の定義は、標準の追跡ドキュメントで定義する必要があります。
Below is a new IANA Registry for SIP Reason Header reason-text strings, associated with their respective protocol type and Reason-param cause values. Per RFC 3326, the Reason-text string is a quoted default string with only human understandability meant. These strings can be changed by local policy.
以下は、それぞれのプロトコルタイプとReason-Paramの原因値に関連付けられたSIP理由ヘッダー理由テキスト文字列の新しいIANAレジストリです。RFC 3326ごとに、理由テキスト文字列は、人間の理解が意味されるとのみのある引用されたデフォルト文字列です。これらの文字列は、ローカルポリシーによって変更できます。
Reason-
Protocol param Reason-Text Reference
-------- ------- ------------ ---------
Preemption Cause=1 UA Preemption RFC 4411
Preemption Cause=2 Reserved Resources RFC 4411
Preempted
Preemption Cause=3 Generic Preemption RFC 4411
Preemption Cause=4 Non-IP Preemption RFC 4411
The following individuals contributed to this effort:
次の個人がこの努力に貢献しました：
Subhasri Dhesikan Gonzalo Camarillo Dave Oran
Subhasri Dhesikan Gonzalo Camarillo Dave Oran
The author thanks these individuals greatly for their aid in this effort.
著者は、これらの個人がこの努力への援助に大いに感謝しています。
To Haluk Keskiner for providing a valued sanity check. To Dean Willis, Rohan Mahy, and Allison Mankin for their belief in and backing of this effort. To Adam Roach and Arun Kumar for helpful comments to this document.
大切な正気チェックを提供してくれたHaluk Keskinerに。ディーン・ウィリス、ローハン・マヒー、アリソン・マンキンに、この努力を信じて支持してくれた。この文書への有益なコメントについては、Adam RoachとArun Kumarに。
Thanks to Mike Pierce for helpful comments and catching a flaw in this spec late in the process (before it was too late).
有益なコメントをしてくれたマイク・ピアスに感謝し、その過程で（手遅れになる前に）この仕様の欠陥をキャッチしてくれてありがとう。
[1] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason Header Field for the Session Initiation Protocol (SIP)", RFC 3326, December 2002.
[1] Schulzrinne、H.、Oran、D。、およびG. Camarillo、「セッション開始プロトコル（SIP）のヘッダーフィールドの理由」、RFC 3326、2002年12月。
[2] 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.
[2] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、 "SIP：SESSION INTIATION Protocol"、RFC 3261、2002年6月。
[3] Camarillo, G., Marshall, W., and J. Rosenberg, "Integration of Resource Management and Session Initiation Protocol (SIP)", RFC 3312, October 2002.
[3] Camarillo、G.、Marshall、W。、およびJ. Rosenberg、「リソース管理とセッション開始プロトコルの統合（SIP）」、RFC 3312、2002年10月。
[4] Schulzrinne, H. and J. Polk, "Communications Resource-Priority Header in the Session Initiation Protocol (SIP)", RFC 4412, February 2006.
[4] Schulzrinne、H。およびJ. Polk、「セッション開始プロトコル（SIP）の通信リソース優先ヘッダー」、RFC 4412、2006年2月。
[5] ITU-T Recommendation Q.850 (1993)
[5] ITU-Tの推奨事項Q.850（1993）
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[6] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[7] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[7] Braden、R.、Zhang、L.、Berson、S.、Herzog、S。、およびS. Jamin、「リソース予約プロトコル（RSVP） - バージョン1機能仕様」、RFC 2205、1997年9月。
[8] J. Manner, G. Karagiannis, A. McDonald, S. Van den Bosch, "NSLP for Quality-of-Service signalling", Work in Progress, September 2005.
[8] J.マナー、G。カラギアンニス、A。マクドナルド、S。ヴァンデンボッシュ、「サービス品質信号のためのNSLP」、2005年9月、進行中の作業。
Author Information
著者情報
James M. Polk Cisco Systems 2200 East President George Bush Turnpike Richardson, Texas 75082 USA
ジェームズM.ポークシスコシステム2200イースト大統領ジョージブッシュターンパイクリチャードソン、テキサス75082 USA
EMail: jmpolk@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。