Network Working Group J. Polk
Request for Comments: 4411 Cisco Systems
Category: Standards Track February 2006
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).
版权所有（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.
本文档提出了会话发起协议（SIP）原因报头的IANA注册扩展，作为会话抢占事件的结果，包括在用户代理（UA）处或网络中涉及基于预约的协议（如资源预约协议（RSVP））的某处的BYE方法请求中或信令中的下一步（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
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原因报头是一种应用层反馈机制，用于同步事件的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）。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共享对话框共享，则会创建原因头[1]，以包含在BYE请求中。这不是这个新标题的唯一方法；[1] 还讨论了CANCEL方法的用法。
This document will define two use cases in which new preemption Reason values are necessary:
本文档将定义两个需要新抢占原因值的用例：
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).
Access Preemption Event（访问抢占事件）-这是指UA收到新的SIP会话请求消息时，该消息的有效R-P值高于与该UA当前活动会话相关的值。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).
网络抢占事件-这是指网络元件（如路由器）在特定接口上达到容量，并且能够根据SIP前提条件[3]中列出的参数，在发出新会话/保留信号时，有状态地选择哪些会话将保持活动状态否则会使该接口过载（可能会对所有会话产生不利影响）。在这种情况下，路由器必须终止一个或多个较低优先级的保留，以便允许该较高优先级的保留访问请求的带宽量（根据某些域的本地策略）。
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.
本文档将介绍这两种情况的语义，并请求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,
本文档将强调现有SIP RFC[3]作为网络抢占事件的起点。RFC 3312使用QoS先决条件保留协议设置SIP交互相关规则，
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).
使用RSVP作为示例协议。这一努力并不排除其他先决条件或今后的议定书工作成为先决条件的手段。NSIS是一种新的预留协议，它指定了一种抢占操作，类似于RSVP的ResvErr消息，该消息涉及[8]中的NSIS NOTIFY消息，带有一个瞬时错误代码0x04000005（资源已抢占）。
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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[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为何会过早中断会话。合适的机制是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提供一种手段，使其能够在适当的情况下以本地确定的方式作出反应（播放特定的音调或音调序列，指向一个特别公告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 |
| |<=======================>|
| | |
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加入R-P为2的新会话（优先级高于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“消失”，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以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.
如果一个会话中有两个UA，并且一个UA必须抢占该会话以接受另一个会话，则BYE方法消息是执行此任务的适当机制。然而，更进一步，如果UA是三方（或更多）特设会议的公共点，并且由于收到更高优先级的会话请求（该UA必须接受）而必须抢占该会议中的所有会话，则必须向该特设会议中的所有UA发送BYE消息。
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:
以下是为访问抢占事件（APE）添加适当原因值的要求列表，如上文所述和图1所示：
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可以通知另一个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.
例如：可能需要将此事件通知已将记录路由头合并到会话设置中的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用户代理之间的中间路由器抢占其一个接口上的一个或多个会话以通过该接口放置更高优先级会话的实例。在RSVP中，存在一种按照[7]：ResvErr消息执行此功能的方法，该消息向下游适当的接收者传播。ResvErr消息能够在其中携带一个代码，指示删除保留的原因。ResvErr不会向上游移动到其他UA。本文档建议生成SIP消息，以将所有相关SIP元素与此抢占事件（包括上游UA）同步。在某些域中，需要创建另一个说明网元抢占会话的原因值。
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]中想象出来，其中有一条NOTIFY错误消息，指示保留已被瞬态错误_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优先级。路由器1和路由器2之间的链路因UA1和UA2之间的会话保留而饱和（在本例中）。
UA1 UA2
\ /
\ /
+--------+ +--------+
| | | |
| RTR1 | | RTR2 |
| Int7-------Int5 |
| | | |
+--------+ +--------+
/ \
/ \
UA3 UA4
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
UA1和UA2之间的会话建立后，UA3邀请UA4加入资源优先级为2的新会话（优先级高于UA1和UA2之间的当前保留）。同样，此INVITE的资源优先级标头中的优先级值被转换为适当的RSVP优先级（也更高）
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会话/RSVP流相对优先）。当这第二个高优先级会话发出信号时，一条路径消息从UA3发送到UA4，导致RESV消息从UA4返回到UA3。由于这两个路由器之间的链路具有容量（图5中的Int7），路由器1将（在本例中）做出决定，或与另一个网络实体通信，该网络实体将做出抢占低优先级BW的决定，以确保完成此高优先级会话预留。向UA2发送一条ResvErr消息。结果是UA2将知道路由器中发生了抢占事件（因为ResvErr消息中有一个错误代码，表示“抢占”）。在这一点上，UA1将不知道这种抢占的任何事情。如果UAs 1和UAs 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在RSVP层发送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 |
|------------------------------------------------->|
| |
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“服务不可用”。由于会话已经建立，因此在这里使用任何一个都是有问题的。如果访问抢占事件的原因值与网络抢占事件的原因值之间需要存在差异，则会更加复杂。前面已经说明了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.
声明所有抢占是平等的是可能的，但不能提供足够的信息。因此，需要另一个原因头值来区分APE和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-创建一种方法，通知远端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需要能够将此抢占事件传送到此会话的SIP部分，就像用户1是会话中的UA一样。以下是这方面的示意图：
**************************
* TDM network *
* +---------+
* User 1 | |
* O ==========>| SIP GW1 |================> UA2
* /|\ ^ | | |
* / \ | +---------+ |
* | * |
**********|*************** | |
| | Preemption |
Preemption ---------> |--------------------->|
Event Indication
**************************
* 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-创建一种通过SIP网关和非IP电话在对话中通知远端UA会话的TDM部分向SIP网关指示抢占事件终止会话的方法。
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一般先占这是一个有限使用先占指示，用于先占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"
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节通过消息流图提供了上述四个原因代码的用例和扩展定义。
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"
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 |
| |<==================>|
| | |
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加入R-P为2的新会话（比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发送一个BYE请求消息，其原因头的值为UA抢占。这将通知远端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中下行，一个NOTIFY在NSIS中。接收抢占错误消息的UA向远端UA生成BYE请求，其中Reason报头具有该值，该值指示在两个或多个UAs之间的某个地方，路由器已管理性抢占该会话。
An example usage of this header value would be:
此标头值的示例用法如下：
Reason: Preemption :cause=2 ;text="Reserved Resources Preempted"
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 |
|---------------------------------------------------->|
| |
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.
上面是图2中路由器2的呼叫流，包括在发送Resv消息的RSVP层。由于图的复杂性，不包括包含所有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.
在收到带有抢占错误代码的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应用也将被推广。如果要实现此原因值，则仅应在最终SIP代理上执行此操作，以便指示实际发生的抢占事件类型的原因值更改为抢占UA将接收的此通用抢占指示。
An example usage of this header value would be:
此标头值的示例用法如下：
Reason: preemption ;cause=3 ;text="Generic Preemption"
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基础设施中，抢占事件发生在非IP部分，该部分指示此呼叫终止是由于抢占。这是SIP网关向被抢占的SIP UA生成的指示，该指示将穿越会话信令中涉及的任何SIP代理（服务器状态问题）。
An example usage of this header value would be:
此标头值的示例用法如下：
Reason: preemption ;cause=4 ;text="Non-IP Preemption"
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") | . .
|<--------------------------------------| . .
| | ............
............
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向会话发送User3信号。一旦建立，在会话/呼叫的非IP部分中存在抢占事件，并且TDM部分能够将这种类型的事件通知SIP-GW。该非IP信号可以转换为SIP信令（转换为BYE会话终止消息）。在这个BYE中，应该有一个Reason头，指示这样一个事件来同步所有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:
本文档将添加到一个现有IANA注册表并创建一个新注册表。SIP原因标头的现有IANA注册表如下所示：
Protocol Value Protocol Cause Reference
-------------- -------------- ---------
SIP Status code RFC 3261
Q.850 Cause value in decimal ITU-T Q.850
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
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响应代码字符串，或取自Q.850原因代码的默认描述。目前，除了这两个来源之外，没有地方注册新的原因文本字符串。由于本文档定义了一个新的原因头协议名称空间，因此在第7.2节中创建了一个新的IANA注册表，仅用于此和未来的原因头协议名称空间（SIP响应代码或Q.850原因值除外），以注册其各自的通用描述性文本字符串。这些文本字符串不具有约束力，只是人类理解的默认值，但它们被认为足够重要，可以拥有自己的注册表。
RFC 4411 creates the new SIP "Reason Header" [1] protocol namespace: "Preemption", with 4 defined cause codes:
RFC 4411创建了新的SIP“原因头”[1]协议名称空间：“抢占”，并定义了4个原因代码：
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"
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):
如果由于在SIP UA接收到RSVP ResvErr消息而使用此名称空间来指示抢占，则应使用以下语法（原因文本是默认字符串；它不是强制性的，并且可能不同）：
Reason: preemption ;cause=2 ;text="Reserved Resources Preempted"
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"
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: preemption ;cause=4 ;text=" Non-IP Preemption"
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.
下面是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
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
苏巴斯里·德西坎·冈萨洛·卡马里洛·戴夫·奥兰
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).
感谢迈克·皮尔斯（Mike Pierce）提供的有用意见，并在过程的后期（在为时已晚之前）发现了本规范中的一个缺陷。
[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）的原因头字段”，RFC3326，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：会话启动协议”，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 22052997年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.Way，G.Karagiannis，A.McDonald，S.Van den Bosch，“服务质量信号NSLP”，在建工程，2005年9月。
Author Information
作者信息
James M. Polk Cisco Systems 2200 East President George Bush Turnpike Richardson, Texas 75082 USA
詹姆斯·M·波尔克思科系统2200美国德克萨斯州东总统乔治·布什收费公路理查森75082
EMail: jmpolk@cisco.com
EMail: 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/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的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。