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
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
Abstract
抽象
This document 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.
この文書では、ユーザエージェント（UA）のいずれかで、セッションのプリエンプションのイベントの結果として、BYEメソッド要求に含まれるセッション開始プロトコル（SIP）ReasonヘッダにIANA登録拡張を提案している、またはネットワークのどこかに関与そのようなリソース予約プロトコル（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 [2]プリエンプションのイベントが発生した理由としてSIP要素を同期させる拡張となります。
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
SIPのReasonヘッダには、イベントのSIP要素を同期させるアプリケーション層フィードバック機構です。特定のイベントは、ここで説明したセッションのプリエンプションを扱っています。 Q.850 [5]を提供
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.
プリエンプションの指標（原因= 8）とプリエンプションは、「回路の再利用のために予約」（原因= 9）。 IPは、回路の概念がないようQ.850原因= 9は、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と（または必要があります）で共有することができる具体的な理由のために終了した場合に、ヘッダは、[1]に作成された理由は、BYE要求に含まれます。これは、この新しいヘッダーのための唯一の方法はなかったです。 [1]また、Cancelメソッドの使用を論じています。
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前提条件に別段の（おそらく悪影響すべてのセッションに影響を与える）、そのインターフェイスが過負荷になること。この場合、ルータは、（いくつかのドメインのローカルポリシーに従って）帯域幅の要求量に、この優先度の高い予約アクセスを可能にするために、より低い優先度の一つ以上の予約を終了しなければなりません。
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.
この文書では、上記のプリエンプション条件のための4つの原因値と、これら2例と理由ヘッダーフィールドのための新しいプロトコル値「プリエンプション」の要求IANA登録のためのセマンティクスをカバーします。また、この文書は現在、既存のSIP応答コードまたはQ.850原因コードによって定義されていない理由は、テキスト文字列のための新しいIANAレジストリを作成します。この新しいレジストリは、SIPのReasonヘッダで使用される将来のプロトコルのために有用であろう。
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]を強調します。例えばプロトコルとしてRSVPを使用して、QoSの前提条件の予約プロトコルを使用してSIPの相互作用を囲むRFC 3312セットルール。その努力は、前提条件の手段になってから、他の前提条件、または将来のプロトコルの作業を排除するものではありませんでした。 NSISはのNSISは、一時的なエラーコード0x04000005（リソースプリエンプション）と[8]にNOTIFYメッセージを含むResvErrメッセージをRSVPと同様先取り動作を指定する新たな予約プロトコルの努力です。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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）は、ユーザエージェントで発生します。 （UACまたはセッションのUAS）はどうなるのユニキャストまたはマルチキャストセッション中のどのUA問題ではありません。ローカルポリシーは、UAの機能性に関する特定のドメインのルールに指示した場合、UA（ユーザーではなく）というセッションがちょうど途中で取り壊された理由を他のUA（複数可）を通知する手段がなければなりません。適切なメカニズムは、BYE方法です。そのセッションが発生したかの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が（何かをするUAのビジュアルディスプレイなどの原因となり、特別なアナウンスURIに向けたポイントを特定のトーンまたはトーンシーケンスを再生）、局部的に決定した方法で反応するための手段を提供します。
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は、3つのリソース優先度のセッションにUA2を招待（レベル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は、2のR-P（UA1とUA2との間の現在のセッションよりも高い優先度）を持つ新しいセッションに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、「ゴーン」、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.
プリエンプションのいかなる特定のタイプが発生していないことをユーザに示すためにプリエンプション指示を受信するUAを構成することが可能であるべきです。そのユーザーがネットワークの動作の詳細を知らないままにすることを好むかもしれないいくつかのドメインがあります。これは、これまでUAからBYEに送信されてから知られているプリエンプション表示を妨げるべきではありません。
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がなければならないこと）受け入れ、その後、BYEメッセージは、アドホック会議のすべてのUAに送信する必要があります。
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 - オンUAは、2つのデバイス間のアクティブなセッションが故意に別のUAからのより高い優先度のセッション要求ための一UAにプリエンプトされていること（同一のアクティブセッション内で）別の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.
例えば：おそらくそのセッションにRecord-Routeヘッダを組み入れた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つ以上のセッションをプリエンプトする例です。適切な受信機に向かって下流に移動ResvErrメッセージ：RSVP内、[7]当たり、この機能を実行する手段が存在します。 ResvErrメッセージは、その中に予約が解体されている理由を示すコードを担持する能力を有します。 ResvErrは、他のUAに上流に移動しません。この文書では、SIPメッセージが上流UAを含む、このプリエンプションイベントに関連するすべての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とネットワークプリエンプションのシナリオを示します。ここで実施例に示されていないNSISは、予約が一時ERROR_SPECの0x04000005でプリエンプトされたことを示すNOTIFYエラーメッセージを表示して[8]から想像することができます。 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 3の資源優先度のセッションにUA2を招待し、受け入れられている（レベル1及び2は、このドメインが高いです）。このSIPシグナリングは、そのフローのための適切なRSVP優先レベルに資源優先度の値を翻訳しました。ルータ1とルータ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 2のリソースプライオリティレベル（UA1とUA2との間の現在の予約よりも高い優先度）を持つ新しいセッションにUA4を招きます。再び、このINVITEのリソースプライオリティヘッダ内の優先度の値（つまりもUA1_UA2セッション/ RSVPフローに対して優先度が高い）は、適切なRSVP優先順位に変換されます。この第二の、優先度の高いセッションが通知された場合、1つのPathメッセージは、バックUA3にUA4から行くRESVメッセージで、その結果、UA3からUA4に行きます。 2つのルータ間のリンクは、（図5にINT7で）容量であるため、ルータ1は、（この例では）決定を下すだろうか、ということを保証するために、優先度の低いBWを先取りする決定を行うことを別のネットワークエンティティと通信しますこの優先度の高いセッションの予約が完了しています。 ResvErrメッセージをUA2に送信されます。結果は、UA2は（ResvErrメッセージは、「先取り」を述べ、その中のエラーコードを持っているので）ルータのプリエンプションのイベントがあったことを知っているだろうということです。この時点で、UA1は、このプリエンプションの何も知らないであろう。 （レコードルートヘッダを挿入おそらく）のUA 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は、図2からルータ2とのコールフローは、ResvErrメッセージを送信するRSVP層に含まれる示します。すべてのUAとルータを含む完全なコールフローは図の複雑さの理由のためにここでは示されていません。 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、「ゴーン」、480「一時的に利用できない」486「ここで忙しい」、および503「サービスを使用できません」。セッションがすでに確立されているので、ここではこれらのいずれかを使用することは疑問です。ネットワークプリエンプションイベントに対してアクセスプリエンプションイベントの理由値との差が存在する必要がある場合はさらに複雑になります。 [5] Q.850の限界は、すでに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.
すべてのプリエンプションが等しいこと状態にすることは可能ですが、十分な情報を提供することはありません。したがって、別のReasonヘッダ値はNPEからAPEを区別する必要があります。
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 - ネットワークプリエンプションのイベントが中間ルータに発生したことを遠端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サーバがセットアップそのセッションにRecord-Routeヘッダを組み込んでいます。
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とのセッションに（TDM電話を使用して）インフラストラクチャの非IPの部分にある場合、それがなかった場合に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におけるReasonヘッダフィールドのプロトコルフィールドの次の新しいプロトコル値を定義する[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一般的なプリエンプションこれは、イベントを一般化するために先取りUAへの最終的な足に使用される限られた使用のプリエンプションを示すものです。
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プリエンプションセッションのプリエンプションは、インフラストラクチャの非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"
理由：先取り;原因= 1;テキスト= "UAプリエンプション" 理由：先取り;原因= 2;テキスト= "予約されたリソースプリエンプト" 理由：先取り;原因= 3;テキスト= "ジェネリックプリエンプション" 理由：先取り;原因= 4 ;テキスト=「非IPプリエンプション」
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"
理由：先取り;原因= 1;テキスト= "UAプリエンプション"
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は、3つの資源優先度のレベル（レベル1及び2は、このドメインが高い）とのセッションにUA2を招きます。 UA1とUA2との間のセッションが確立された後、UA3は、2のR-P（UA1に現在のセッションよりも高い優先度）を持つ新しいセッションにUA2を招きます。このドメイン内のローカルポリシーは、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プリエンプションの値とReasonヘッダと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.
ルータは、予約の流れを先取りし、予約エラーメッセージを生成した：ResvErrはRSVP下流走行、およびNSISにNOTIFY。プリエンプションエラーメッセージを受信するUAは、どこか二つ以上のUA間、ルータが管理このセッションをプリエンプトしたことを示すこの値Reasonヘッダと遠側UAに向かってBYE要求を生成します。
An example usage of this header value would be:
このヘッダの値の使用例は次のようになります。
Reason: Preemption :cause=2 ;text="Reserved Resources Preempted"
理由：プリエンプション：原因= 2;テキスト=「予約されたリソースプリエンプト」
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.
上記RESVメッセージを送信するRSVP層に含まれる図2からルータ2とのコールフローがあります。すべてのUAとルータを含む完全なコールフローは図の複雑さの理由のために含まれていません。 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.
このイベントが発生した理由を先取りエラーコードと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を提供したくないインフラのためです。 UAがReasonヘッダに含まれ、そして特定のドメインが最適ではないとしてこれを発現させ、表示を一般化したかったプリエンプションイベントのタイプを示すであろうコードを有することが可能です。貴重なトラフィック分析や他のNMアプリケーションは、同様に一般化されるように、これは、これらのドメイン内の最初の兆候にすることはできません。この原因値が実現される場合、それだけプリエンプションイベントのタイプを示す原因値が実際に発生するように、最終的なSIPプロキシで行われるべきでプリエンプトUAが受信するこの一般プリエンプション表示に変更されます。
An example usage of this header value would be:
このヘッダの値の使用例は次のようになります。
Reason: preemption ;cause=3 ;text="Generic Preemption"
理由：先取り;原因= 3;テキスト=「ジェネリックプリエンプション」
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インフラストラクチャに存在し、プリエンプションイベントは、非IP部で発生し、この着信がプリエンプションに起因したことをその部分によって示されました。これは、SIPプロキシがセッションシグナリング（サーバの状態の質問）に関与している方横断、プリエンプトされているSIP UAに向かってSIPゲートウェイによって生成される指標です。
An example usage of this header value would be:
このヘッダの値の使用例は次のようになります。
Reason: preemption ;cause=4 ;text="Non-IP Preemption"
理由：先取り;原因= 4;テキスト=「非IPプリエンプション」
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.非IPプリエンプションフロー
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は、セッションにユーザ3に信号を送ります。一度確立され、そこセッション/呼の非IP部のプリエンプションのイベントであり、TDM部分は、イベントのこのタイプのSIP GWに通知する能力を有します。この非IP信号（BYEセッション終了メッセージに）SIPシグナリングに変換することができます。このBYE内で、すべてのSIP要素を同期するためにそのようなイベントを示すReasonヘッダが存在すべきです。
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:
この文書では、1つの既存のIANAレジストリに追加し、1つの新しいレジストリを作成します。次のようにSIPのReasonヘッダのための既存のIANAレジストリは次のとおりです。
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節では、既存のReasonヘッダのために示されているが、理由-テキストは、すべてのSIP応答コードからSIPレスポンスコード文字列、またはQ.850原因コードからデフォルトの記述から取られました。現在、これらの二つのソース以外からの新しい理由 - テキスト文字列を登録する場所がありません。このドキュメントは新しいReasonヘッダのプロトコルの名前空間を定義しているので、新しいIANAレジストリはそれぞれの一般的な説明のテキスト文字列を登録するだけで、このと（SIP応答コードまたはQ.850原因値以外の）将来のReasonヘッダのプロトコルの名前空間については、セクション7.2で作成されました。これらのテキスト文字列は、人間の理解のための非結合、単にデフォルトですが、彼らは自分のレジストリを持っているために十分に重要なものとみなされます。
RFC 4411 creates the new SIP "Reason Header" [1] protocol namespace: "Preemption", with 4 defined cause codes:
4つの定義された原因コードと「プリエンプション」、：RFC 4411には、新しいSIP「Reasonヘッダ」[1]のプロトコルの名前空間を作成します。
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"
理由：先取り;原因= 1;テキスト= "UAプリエンプション"
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"
理由：先取り;原因= 2;テキスト=「予約されたリソースプリエンプト」
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"
理由：先取り;原因= 3;テキスト=「ジェネリックプリエンプション」
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: preemption ;cause=4 ;text=" Non-IP Preemption"
理由：先取り;原因= 4;テキスト=「非IPプリエンプション」
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.
以下は、それぞれのプロトコルタイプと理由-PARAM原因値に関連付けられた新しいIANAレジストリSIP理由ヘッダー理由テキスト文字列が、あります。 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ゴンサロ・カマリロデイブ・オラン
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に大切な健全性チェックを提供するため。この努力の彼らの信念やバッキングのためのディーン・ウィリス、ローハンマーイ、およびアリソンマンキンへ。このドキュメントの役に立つコメントのためのアダム・ローチとアルン・クマールへ。
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.、オラン、D.、およびG.カマリロ、RFC 3326 "セッション開始プロトコル（SIP）理由ヘッダーフィールド" 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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、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]カマリロ、G.、マーシャル、W.、およびJ.ローゼンバーグ、 "リソース管理の統合およびセッション開始プロトコル（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.ポーク、 "セッション開始プロトコル（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]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[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]ブレーデン、R.、チャン、L.、Berson氏、S.、ハーツォグ、S.、およびS.ヤミン、 "リソース予約プロトコル（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. Karagiannis、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
メールアドレス：jmpolk@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。