Network Working Group F. Baker
Request for Comments: 4542 J. Polk
Category: Informational Cisco Systems
May 2006
Network Working Group F. Baker
Request for Comments: 4542 J. Polk
Category: Informational Cisco Systems
May 2006
Implementing an Emergency Telecommunications Service (ETS) for Real-Time Services in the Internet Protocol Suite
为Internet协议套件中的实时服务实施紧急电信服务（ETS）
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
RFCs 3689 and 3690 detail requirements for an Emergency Telecommunications Service (ETS), of which an Internet Emergency Preparedness Service (IEPS) would be a part. Some of these types of services require call preemption; others require call queuing or other mechanisms. IEPS requires a Call Admission Control (CAC) procedure and a Per Hop Behavior (PHB) for the data that meet the needs of this architecture. Such a CAC procedure and PHB is appropriate to any service that might use H.323 or SIP to set up real-time sessions. The key requirement is to guarantee an elevated probability of call completion to an authorized user in time of crisis.
RFCs 3689和3690详细说明了应急电信服务（ETS）的要求，其中互联网应急准备服务（IEPS）将是其中的一部分。其中一些类型的服务需要呼叫抢占；另一些则需要呼叫队列或其他机制。IEPS需要一个呼叫允许控制（CAC）过程和一个每跳行为（PHB），以满足该体系结构的需要。这样的CAC过程和PHB适用于可能使用H.323或SIP建立实时会话的任何服务。关键的要求是保证在危机时刻提高授权用户完成呼叫的概率。
This document primarily discusses supporting ETS in the context of the US Government and NATO, because it focuses on the Multi-Level Precedence and Preemption (MLPP) and Government Emergency Telecommunication Service (GETS) standards. The architectures described here are applicable beyond these organizations.
本文件主要讨论在美国政府和北约的背景下支持ETS，因为其重点是多级优先和抢占（MLPP）和政府紧急电信服务（GETS）标准。这里描述的体系结构适用于这些组织之外的组织。
Table of Contents
目录
1. Overview of the Internet Emergency Preference Service
Problem and Proposed Solutions ..................................3
1.1. Emergency Telecommunications Services ......................3
1.1.1. Multi-Level Preemption and Precedence ...............4
1.1.2. Government Emergency Telecommunications Service .....6
1.2. Definition of Call Admission ...............................6
1.3. Assumptions about the Network ..............................7
1.4. Assumptions about Application Behavior .....................7
1.5. Desired Characteristics in an Internet Environment .........9
1.6. The Use of Bandwidth as a Solution for QoS ................10
2. Solution Proposal ..............................................11
2.1. Call Admission/Preemption Procedure .......................12
2.2. Voice Handling Characteristics ............................15
2.3. Bandwidth Admission Procedure .............................17
2.3.1. RSVP Admission Using Policy for Both
Unicast and Multicast Sessions .....................17
2.3.2. RSVP Scaling Issues ................................19
2.3.3. RSVP Operation in Backbones and Virtual
Private Networks (VPNs) ............................19
2.3.4. Interaction with the Differentiated
Services Architecture ..............................21
2.3.5. Admission Policy ...................................21
2.4. Authentication and Authorization of Calls Placed ..........23
2.5. Defined User Interface ....................................23
3. Security Considerations ........................................24
4. Acknowledgements ...............................................24
5. References .....................................................25
5.1. Normative References ......................................25
5.2. Informative References ....................................27
Appendix A. 2-Call Preemption Example using RSVP .................29
1. Overview of the Internet Emergency Preference Service
Problem and Proposed Solutions ..................................3
1.1. Emergency Telecommunications Services ......................3
1.1.1. Multi-Level Preemption and Precedence ...............4
1.1.2. Government Emergency Telecommunications Service .....6
1.2. Definition of Call Admission ...............................6
1.3. Assumptions about the Network ..............................7
1.4. Assumptions about Application Behavior .....................7
1.5. Desired Characteristics in an Internet Environment .........9
1.6. The Use of Bandwidth as a Solution for QoS ................10
2. Solution Proposal ..............................................11
2.1. Call Admission/Preemption Procedure .......................12
2.2. Voice Handling Characteristics ............................15
2.3. Bandwidth Admission Procedure .............................17
2.3.1. RSVP Admission Using Policy for Both
Unicast and Multicast Sessions .....................17
2.3.2. RSVP Scaling Issues ................................19
2.3.3. RSVP Operation in Backbones and Virtual
Private Networks (VPNs) ............................19
2.3.4. Interaction with the Differentiated
Services Architecture ..............................21
2.3.5. Admission Policy ...................................21
2.4. Authentication and Authorization of Calls Placed ..........23
2.5. Defined User Interface ....................................23
3. Security Considerations ........................................24
4. Acknowledgements ...............................................24
5. References .....................................................25
5.1. Normative References ......................................25
5.2. Informative References ....................................27
Appendix A. 2-Call Preemption Example using RSVP .................29
1. Overview of the Internet Emergency Preference Service Problem and Proposed Solutions
1. Internet紧急偏好服务问题概述和建议的解决方案
[RFC3689] and [RFC3690] detail requirements for an Emergency Telecommunications Service (ETS), of which an Internet Emergency Preference Service (IEPS) would be a part. Some of these types of services require call preemption; others require call queuing or other mechanisms. The key requirement is to guarantee an elevated probability of call completion to an authorized user in time of crisis.
[RFC3689]和[RFC3690]紧急电信服务（ETS）的详细要求，其中互联网紧急偏好服务（IEPS）将是其中的一部分。其中一些类型的服务需要呼叫抢占；另一些则需要呼叫队列或其他机制。关键的要求是保证在危机时刻提高授权用户完成呼叫的概率。
IEPS requires a Call Admission Control procedure and a Per Hop Behavior for the data that meet the needs of this architecture. Such a CAC procedure and PHB is appropriate to any service that might use H.323 or SIP to set up real-time sessions. These obviously include but are not limited to Voice and Video applications, although at this writing the community is mostly thinking about Voice on IP, and many of the examples in the document are taken from that environment.
IEPS需要一个呼叫允许控制过程和满足此体系结构需要的数据的每跳行为。这样的CAC过程和PHB适用于可能使用H.323或SIP建立实时会话的任何服务。这些显然包括但不限于语音和视频应用，尽管在撰写本文时，社区主要考虑的是IP语音，文档中的许多示例都取自该环境。
In a network where a call permitted initially is not denied or rejected at a later time, capacity admission procedures performed only at the time of call setup may be sufficient. However, in a network where session status can be reviewed by the network and preempted or denied due to changes in routing (when the new routes lack capacity to carry calls switched to them) or changes in offered load (where higher precedence calls supersede existing calls), maintaining a continuing model of the status of the various calls is required.
在最初允许的呼叫在以后没有被拒绝或拒绝的网络中，仅在呼叫建立时执行的容量接纳过程可能就足够了。然而，在一个网络中，由于路由的变化（当新路由没有能力承载切换到它们的呼叫时）或提供的负载的变化（更高优先级的呼叫取代现有的呼叫），会话状态可以被网络审查并抢占或拒绝，需要维护各种呼叫状态的连续模型。
Before doing so, however, let us discuss the problem that ETS (and therefore IEPS) is intended to solve and the architecture of the system. The Emergency Telecommunications Service [ITU.ETS.E106] is a successor to and generalization of two services used in the United States: Multi-Level Precedence and Preemption (MLPP), and the Government Emergency Telecommunication Service (GETS). Services based on these models are also used in a variety of countries throughout the world, both Public Switched Telephone Network (PSTN) and Global System for Mobile Communications (GSM)-based. Both of these services are designed to enable an authorized user to obtain service from the telephone network in times of crisis. They differ primarily in the mechanisms used and number of levels of precedence acknowledged.
然而，在这样做之前，让我们先讨论一下ETS（以及IEPS）要解决的问题和系统的体系结构。紧急电信服务[ITU.ETS.E106]是美国使用的两种服务的继承和推广：多级优先和抢占（MLPP）和政府紧急电信服务（GETS）。基于这些模型的服务也在世界各地的许多国家使用，包括基于公共交换电话网（PSTN）和全球移动通信系统（GSM）的国家。这两项服务都旨在使授权用户能够在危机时刻从电话网络获得服务。它们的主要区别在于使用的机制和承认的优先级别的数量。
The Assured Service is designed as an IP implementation of an existing ITU-T/NATO/DoD telephone system architecture known as Multi-Level Precedence and Preemption [ITU.MLPP.1990] [ANSI.MLPP.Spec] [ANSI.MLPP.Supp], or MLPP. MLPP is an architecture for a prioritized call handling service such that in times of emergency in the relevant NATO and DoD commands, the relative importance of various kinds of communications is strictly defined, allowing higher-precedence communication at the expense of lower-precedence communications. This document describes NATO and US Department of Defense uses of MLPP, but the architecture and standard are applicable outside of these organizations.
保证服务设计为现有ITU-T/NATO/DoD电话系统架构的IP实现，称为多级优先和抢占[ITU.MLPP.1990][ANSI.MLPP.Spec][ANSI.MLPP.Supp]或MLPP。MLPP是一种优先呼叫处理服务架构，在相关北约和国防部司令部的紧急情况下，严格定义各种通信的相对重要性，允许以较低优先级通信为代价进行较高优先级的通信。本文件描述了北约和美国国防部对MLPP的使用，但体系结构和标准适用于这些组织以外的组织。
These precedences, in descending order, are:
这些先例按降序排列如下：
Flash Override Override: used by the Commander in Chief, Secretary of Defense, and Joint Chiefs of Staff, commanders of combatant commands when declaring the existence of a state of war. Commanders of combatant commands when declaring Defense Condition One or Defense Emergency or Air Defense Emergency and other national authorities that the President may authorize in conjunction with Worldwide Secure Voice Conferencing System conferences. Flash Override Override cannot be preempted. This precedence level is not enabled on all DoD networks.
闪速覆盖：由总司令、国防部长、参谋长联席会议、作战司令部指挥官在宣布战争状态时使用。作战司令部指挥官在宣布国防状况为一级或国防紧急情况或防空紧急情况时，以及总统可能授权的其他国家当局与全球安全语音会议系统会议。无法抢占闪存覆盖。并非所有国防部网络都启用此优先级。
Flash Override: used by the Commander in Chief, Secretary of Defense, and Joint Chiefs of Staff, commanders of combatant commands when declaring the existence of a state of war. Commanders of combatant commands when declaring Defense Condition One or Defense Emergency and other national authorities the President may authorize. Flash Override cannot be preempted in the DSN.
闪速覆盖：由总司令、国防部长、参谋长联席会议、作战司令部指挥官在宣布战争状态时使用。作战司令部指挥官在宣布国防状况为一级或国防紧急状态时，以及总统可能授权的其他国家当局。无法在DSN中抢占闪存覆盖。
Flash: reserved generally for telephone calls pertaining to command and control of military forces essential to defense and retaliation, critical intelligence essential to national survival, conduct of diplomatic negotiations critical to the arresting or limiting of hostilities, dissemination of critical civil alert information essential to national survival, continuity of federal government functions essential to national survival, fulfillment of critical internal security functions essential to national survival, or catastrophic events of national or international significance.
Flash：一般用于与指挥和控制对防御和报复至关重要的军事力量、对国家生存至关重要的关键情报、进行对逮捕或限制敌对行动至关重要的外交谈判有关的电话通话，传播对国家生存至关重要的关键民事警报信息，延续对国家生存至关重要的联邦政府职能，履行对国家生存至关重要的关键内部安全职能，或发生具有国家或国际意义的灾难性事件。
Immediate: reserved generally for telephone calls pertaining to situations that gravely affect the security of national and allied forces, reconstitution of forces in a post-attack period,
即时：一般用于与严重影响国家和盟军安全的情况有关的电话呼叫，在袭击后重建部队，
intelligence essential to national security, conduct of diplomatic negotiations to reduce or limit the threat of war, implementation of federal government actions essential to national survival, situations that gravely affect the internal security of the nation, Civil Defense actions, disasters or events of extensive seriousness having an immediate and detrimental effect on the welfare of the population, or vital information having an immediate effect on aircraft, spacecraft, or missile operations.
对国家安全至关重要的情报、开展外交谈判以减少或限制战争威胁、实施对国家生存至关重要的联邦政府行动、严重影响国家内部安全的局势、民防行动、，对民众福利有直接和有害影响的严重灾难或事件，或对飞机、航天器或导弹作战有直接影响的重要信息。
Priority: reserved generally for telephone calls requiring expeditious action by called parties and/or furnishing essential information for the conduct of government operations.
优先权：一般用于要求被叫方迅速采取行动和/或为政府行动提供必要信息的电话。
Routine: designation applied to those official government communications that require rapid transmission by telephonic means but do not require preferential handling.
例行：指需要通过电话快速传输但不需要优先处理的官方政府通信。
MLPP is intended to deliver a higher probability of call completion to the more important calls. The rule, in MLPP, is that more important calls override less important calls when congestion occurs within a network. Station-based preemption is used when a more important call needs to be placed to either party in an existing call. Trunk-based preemption is used when trunk bandwidth needs to be reallocated to facilitate a higher-precedence call over a given path in the network. In both station- and trunk-based preemption scenarios, preempted parties are positively notified, via preemption tone, that their call can no longer be supported. The same preemption tone is used, regardless of whether calls are terminated for the purposes of station- of trunk-based preemption. The remainder of this discussion focuses on trunk-based preemption issues.
MLPP旨在为更重要的呼叫提供更高的呼叫完成概率。MLPP中的规则是，当网络发生拥塞时，更重要的呼叫会覆盖不太重要的呼叫。当需要向现有呼叫中的任何一方发出更重要的呼叫时，使用基于站点的抢占。当需要重新分配中继带宽以促进网络中给定路径上的更高优先级呼叫时，使用基于中继的抢占。在基于站点和中继的抢占方案中，抢占方都会通过抢占音被积极通知其呼叫不再受支持。无论是否出于基于中继站的抢占目的而终止呼叫，都使用相同的抢占音。本讨论的其余部分将重点讨论基于中继的抢占问题。
MLPP is built as a proactive system in which callers must assign one of the precedence levels listed above at call initiation; this precedence level cannot be changed throughout that call. If an elevated status is not assigned by a user at call initiation time, the call is assumed to be "routine". If there is end-to-end capacity to place a call, any call may be placed at any time. However, when any trunk group (in the circuit world) or interface (in an IP world) reaches a utilization threshold, a choice must be made as to which calls to accept or allow to continue. The system will seize the trunk(s) or bandwidth necessary to place the more important calls in preference to less important calls by preempting an existing call (or calls) of lower precedence to permit a higher-precedence call to be placed.
在上述MLPP系统中，必须为主动调用启动分配一个优先级别的主动调用；在整个调用过程中不能更改此优先级。如果用户在呼叫启动时未分配提升状态，则假定呼叫为“例行”。如果有端到端容量拨打电话，则可以随时拨打任何电话。但是，当任何中继组（在电路世界中）或接口（在IP世界中）达到利用率阈值时，必须选择接受或允许继续哪些调用。系统将通过抢占优先级较低的现有呼叫（或多个呼叫）以允许放置优先级较高的呼叫，从而抢占必要的中继线或带宽，以优先放置较重要的呼叫而不是较不重要的呼叫。
More than one call might properly be preempted if more trunks or bandwidth is necessary for this higher precedence call. A video call (perhaps of 384 KBPS, or 6 trunks) competing with several lower-precedence voice calls is a good example of this situation.
如果更高优先级的呼叫需要更多的中继线或带宽，则可以正确地抢占多个呼叫。一个视频呼叫（可能是384 KBPS，或6个中继）与几个优先级较低的语音呼叫竞争就是这种情况的一个很好的例子。
A US service similar to MLPP and using MLPP signaling technology, but built for use in civilian networks, is the Government Emergency Telecommunications Service (GETS). This differs from MLPP in two ways: it does not use preemption, but rather reserves bandwidth or queues calls to obtain a high probability of call completion, and it has only two levels of service: "Routine" and "Priority".
美国政府紧急电信服务（GETS）是一项类似于MLPP的服务，使用MLPP信令技术，但用于民用网络。这与MLPP在两个方面不同：它不使用抢占，而是保留带宽或排队呼叫以获得较高的呼叫完成概率，并且它只有两个服务级别：“例程”和“优先级”。
GETS is described here as another example. Similar architectures are applied by other governments and organizations.
GETS在这里描述为另一个示例。其他政府和组织也采用了类似的体系结构。
Traditionally, in the PSTN, Call Admission Control (CAC) has had the responsibility of implementing bandwidth available thresholds (e.g., to limit resources consumed by some traffic) and determining whether a caller has permission (e.g., is an identified subscriber, with identify attested to by appropriate credentials) to use an available circuit. IEPS, or any emergency telephone service, has additional options that it may employ to improve the probability of call completion:
传统上，在PSTN中，呼叫接纳控制（CAC）负责实现可用带宽阈值（例如，限制某些业务消耗的资源）并确定呼叫者是否具有权限（例如，是已识别的订户，其标识由适当的凭证证明）使用可用的电路。IEPS或任何紧急电话服务都有其他选项，可用于提高通话完成的概率：
o The call may be authorized to use other networks that it would not normally use;
o 该呼叫可被授权使用其通常不会使用的其他网络；
o The network may preempt other calls to free bandwidth;
o 网络可以抢占其他呼叫以释放带宽；
o The network may hold the call and place it when other calls complete; or
o 网络可以保留呼叫，并在其他呼叫完成时进行呼叫；或
o The network may use different bandwidth availability thresholds than are used for other calls.
o 网络可能使用与其他呼叫不同的带宽可用性阈值。
At the completion of CAC, however, the caller either has a circuit that he or she is authorized to use or has no circuit. Since the act of preemption or consideration of alternative bandwidth sources is part and parcel of the problem of providing bandwidth, the authorization step in bandwidth provision also affects the choice of networks that may be authorized to be considered. The three cannot be separated. The CAC procedure finds available bandwidth that the caller is authorized to use and preemption may in some networks be part of making that happen.
然而，在CAC完成时，呼叫者要么拥有他或她被授权使用的电路，要么没有电路。由于抢占或考虑替代带宽源的行为是提供带宽问题的一部分，因此带宽提供中的授权步骤也会影响可能被授权考虑的网络的选择。三者不能分离。CAC过程发现调用者有权使用的可用带宽，在某些网络中，抢占可能是实现这一点的一部分。
IP networks generally fall into two categories: those with constrained bandwidth, and those that are massively over-provisioned. In a network where over any interval that can be measured (including sub-second intervals) capacity exceeds offered load by at least 2:1, the jitter and loss incurred in transit are nominal. This is generally a characteristic of properly engineered Ethernet LANs and of optical networks (networks that measure their link speeds in multiples of 51 MBPS); in the latter, circuit-switched networking solutions such as Asynchronous Transfer Mode (ATM), MPLS, and GMPLS can be used to explicitly place routes, which improves the odds a bit.
IP网络通常分为两类：带宽受限的网络和大量过度配置的网络。在一个网络中，在任何可以测量的间隔（包括亚秒间隔）上，容量超过提供的负载至少2:1，在传输过程中产生的抖动和损耗是正常的。这通常是经过适当设计的以太网LAN和光网络（以51Mbps的倍数测量其链路速度的网络）的特征；在后者中，电路交换网络解决方案（如异步传输模式（ATM）、MPLS和GMPLS）可用于显式地放置路由，从而稍微提高了几率。
Between those networks, in places commonly called "inter-campus links", "access links", or "access networks", for various reasons including technology (e.g., satellite links) and cost, it is common to find links whose offered load can approximate or exceed the available capacity. Such events may be momentary or may occur for extended periods of time.
在这些网络之间，在通常称为“校际链路”、“接入链路”或“接入网络”的地方，由于各种原因，包括技术（例如卫星链路）和成本，通常会发现其提供的负载接近或超过可用容量的链路。此类事件可能是暂时的，也可能会持续较长时间。
In addition, primarily in tactical deployments, it is common to find bandwidth constraints in the local infrastructure of networks. For example, the US Navy's network afloat connects approximately 300 ships, via satellite, to five network operation centers (NOCs), and those NOCs are in turn interconnected via the Defense Information Systems Agency (DISA) backbone. A typical ship may have between two and six radio systems aboard, often at speeds of 64 KBPS or less. In US Army networks, current radio technology likewise limits tactical communications to links below 100 KBPS.
此外，主要在战术部署中，在网络的本地基础设施中发现带宽限制是很常见的。例如，美国海军的海上网络通过卫星将大约300艘舰船连接到五个网络运营中心（NOC），而这些NOC又通过国防信息系统局（DISA）主干网互连。一艘典型的船上可能有两到六个无线电系统，通常速度为64 KBPS或更低。在美国陆军网络中，当前的无线电技术同样将战术通信限制在100kbps以下的链路上。
Over this infrastructure, military communications expect to deploy voice communication systems (30-80 KBPS per session) and video conferencing using MPEG 2 (3-7 MBPS) and MPEG 4 (80 KBPS to 800 KBPS), in addition to traditional mail, file transfer, and transaction traffic.
在这个基础设施上，除了传统的邮件、文件传输和事务通信之外，军事通信部门还希望部署使用MPEG 2（3-7 MBPS）和MPEG 4（80 KBPS到800 KBPS）的语音通信系统（每个会话30-80 KBPS）和视频会议。
Parekh and Gallagher published a series of papers [Parekh1] [Parekh2] analyzing what is necessary to ensure a specified service level for a stream of traffic. In a nutshell, they showed that to predict the behavior of a stream of traffic in a network, one must know two things:
Parekh和Gallagher发表了一系列论文[Parekh1][Parekh2]，分析了确保交通流达到特定服务水平的必要条件。简而言之，他们表明，要预测网络中流量流的行为，必须知道两件事：
o the rate and arrival distribution with which traffic in a class is introduced to the network, and
o 将类中的流量引入网络的速率和到达分布，以及
o what network elements will do, in terms of the departure distribution, injected delay jitter, and loss characteristics, with the traffic they see.
o 在出发分布、注入延迟抖动和损失特性方面，网络元素将如何处理他们看到的流量。
For example, TCP tunes its effective window (the amount of data it sends per round trip interval) so that the ratio of the window and the round trip interval approximate the available capacity in the network. As long as the round trip delay remains roughly stable and loss is nominal (which are primarily behaviors of the network), TCP is able to maintain a predictable level of throughput. In an environment where loss is random or in which delays wildly vary, TCP behaves in a far less predictable manner.
例如，TCP调整其有效窗口（每个往返间隔发送的数据量），以便窗口和往返间隔的比率接近网络中的可用容量。只要往返延迟保持大致稳定且损失为标称值（主要是网络行为），TCP就能够保持可预测的吞吐量水平。在丢失是随机的或延迟变化很大的环境中，TCP的行为远不如预期。
Voice and video systems, in the main, are designed to deliver a fixed level of quality as perceived by the user. (Exceptions are systems that select rate options over a broad range to adapt to ambient loss characteristics. These deliver broadly fluctuating perceived quality and have not found significant commercial applicability.) Rather, they send traffic at a rate specified by the codec depending on what it perceives is required. In an MPEG-4 system, for example, if the camera is pointed at a wall, the codec determines that an 80 KBPS data stream will describe that wall and issues that amount of traffic. If a person walks in front of the wall or the camera is pointed an a moving object, the codec may easily send 800 KBPS in its effort to accurately describe what it sees. In commercial broadcast sports, which may line up periods in which advertisements are displayed, the effect is that traffic rates suddenly jump across all channels at certain times because the eye-catching ads require much more bandwidth than the camera pointing at the green football field.
语音和视频系统主要用于提供用户感知的固定质量水平。（例外情况是，系统在很大范围内选择速率选项，以适应环境损耗特性。这些系统提供的感知质量波动很大，并且没有发现明显的商业适用性。）相反，它们按照编解码器指定的速率发送流量，这取决于所需的感知。例如，在MPEG-4系统中，如果相机指向墙，则编解码器确定80 KBPS的数据流将描述该墙并发出该流量。如果一个人走在墙前，或者摄像机被指向一个移动的物体，编解码器可以轻松地发送800 KBPS的信息，以准确描述它所看到的东西。在商业广播体育节目中，广告播放的时段可能会排成一行，其效果是，在某些时候，所有频道的流量都会突然激增，因为引人注目的广告比指向绿色足球场的摄像机需要更多的带宽。
As described in [RFC1633], when dealing with a real-time application, there are basically two things one must do to ensure Parekh's first requirement. To ensure that one knows how much offered load the application is presenting, one must police (measure load offered and discard excess) traffic entering the network. If that policing behavior has a debilitating effect on the application, as non-negligible loss has on voice or video, one must admit sessions judiciously according to some policy. A key characteristic of that policy must be that the offered load does not exceed the capacity dedicated to the application.
如[RFC1633]所述，在处理实时应用程序时，基本上必须做两件事来确保Parekh的第一个需求。为了确保知道应用程序提供了多少负载，必须监控（测量提供的负载并丢弃多余的）进入网络的流量。如果这种监管行为对应用程序有削弱作用，就像对语音或视频造成的不可忽略的损失一样，那么必须根据某些策略明智地承认会话。该策略的一个关键特征必须是提供的负载不超过应用程序专用的容量。
In the network, the other thing one must do is ensure that the application's needs are met in terms of loss, variation in delay, and end-to-end delay. One way to do this is to supply sufficient bandwidth so that loss and jitter are nominal. Where that cannot be accomplished, one must use queuing technology to deterministically apply bandwidth to accomplish the goal.
在网络中，必须做的另一件事是确保应用程序的需求在损失、延迟变化和端到端延迟方面得到满足。实现这一点的一种方法是提供足够的带宽，以便损耗和抖动是正常的。在无法实现的情况下，必须使用排队技术决定性地应用带宽来实现目标。
The key elements of the Internet Emergency Preference Service include the following:
互联网应急偏好服务的关键要素包括：
Precedence Level Marking each call: Call initiators choose the appropriate precedence level for each call based on the user-perceived importance of the call. This level is not to be changed for the duration of the call. The call before and the call after are independent with regard to this level choice.
优先级别标记每个呼叫：呼叫发起人根据用户感知的呼叫重要性为每个呼叫选择适当的优先级别。在通话期间不得更改此级别。关于这个级别的选择，之前的调用和之后的调用是独立的。
Call Admission/Preemption Policy: There is likewise a clear policy regarding calls that may be in progress at the called instrument. During call admission (SIP/H.323), if they are of lower precedence, they must make way according to a prescribed procedure. All callers on the preempted call must be informed that the call has been preempted, and the call must make way for the higher-precedence call.
呼叫接纳/抢占策略：同样，对于在被呼叫仪器上进行的呼叫，也有明确的策略。在呼叫接纳（SIP/H.323）期间，如果它们的优先级较低，则必须按照规定的程序让路。必须通知抢占呼叫上的所有呼叫者该呼叫已被抢占，并且该呼叫必须为更高优先级的呼叫让路。
Bandwidth Admission Policy: There is a clear bandwidth admission policy: sessions may be placed that assert any of several levels of precedence, and in the event that there is demand and authorization is granted, other sessions will be preempted to make way for a call of higher precedence.
带宽许可策略：有一个明确的带宽许可策略：可以放置声明多个优先级中任何一个级别的会话，并且在有需求且授权被授予的情况下，其他会话将被抢占，以便为更高优先级的调用让路。
Authentication and Authorization of calls placed: Unauthorized attempts to place a call at an elevated status are not permitted. In the telephone system, this is managed by controlling the policy applied to an instrument by its switch plus a code produced by the caller identifying himself or herself to the switch. In the Internet, such characteristics must be explicitly signaled.
呼叫的身份验证和授权：不允许未经授权尝试将呼叫置于提升状态。在电话系统中，这是通过控制交换机加上呼叫者在交换机上识别自己的代码应用于仪器的策略来管理的。在互联网上，必须明确指出这些特征。
Voice handling characteristics: A call made, in the telephone system, gets a circuit and provides the means for the callers to conduct their business without significant impact as long as their call is not preempted. In a VoIP system, one would hope for essentially the same service.
话音处理特性：在电话系统中，只要呼叫者的呼叫没有被抢占，呼叫就会得到一条线路，并为呼叫者提供在不造成重大影响的情况下开展业务的手段。在VoIP系统中，人们希望基本上使用相同的服务。
Defined User Interface: If a call is preempted, the caller and the callee are notified via a defined signal, so that they know that their call has been preempted and that at this instant there is no alternative circuit available to them at that precedence level.
定义的用户界面：如果呼叫被抢占，则通过定义的信号通知呼叫者和被呼叫者，以便他们知道自己的呼叫已被抢占，并且此时在该优先级上没有可供选择的电路。
A VoIP implementation of the Internet Emergency Preference Service must, by definition, provide those characteristics.
根据定义，互联网紧急偏好服务的VoIP实现必须提供这些特征。
There is a discussion in Internet circles concerning the relationship of bandwidth to QoS procedures, which needs to be put to bed before this procedure can be adequately analyzed. The issue is that it is possible and common in certain parts of the Internet to solve the problem with bandwidth. In LAN environments, for example, if there is significant loss between any two switches or between a switch and a server, the simplest and cheapest solution is to buy the next faster interface: substitute 100 MBPS for 10 MBPS Ethernet, 1 gigabit for 100 MBPS, or, for that matter, upgrade to a 10-gigabit Ethernet. Similarly, in optical networking environments, the simplest and cheapest solution is often to increase the data rate of the optical path either by selecting a faster optical carrier or deploying an additional lambda. In places where the bandwidth can be over-provisioned to a point where loss or queuing delay are negligible, 10:1 over-provisioning is often the cheapest and surest solution and, by the way, offers a growth path for future requirements. However, there are many places in communication networks where the provision of effectively infinite bandwidth is not feasible, including many access networks, satellite communications, fixed wireless, airborne and marine communications, island connections, and connections to regions in which fiber optic connections are not cost-effective. It is in these places where the question of resource management is relevant. Specifically, we do not recommend the deployment of significant QoS procedures on links in excess of 100 MBPS apart from the provision of aggregated services that provide specific protection to the stability of the network or the continuity of real-time traffic as a class, as the mathematics of such circuits do not support this as a requirement.
在互联网界有一个关于带宽与QoS过程的关系的讨论，在对该过程进行充分分析之前，需要先对其进行讨论。问题是，在互联网的某些部分，用带宽解决问题是可能的，也是常见的。例如，在LAN环境中，如果任何两个交换机之间或交换机与服务器之间存在重大损失，最简单、最便宜的解决方案是购买下一个更快的接口：用100 MBPS替换10 MBPS以太网，用1 Gbps替换100 MBPS，或者升级到10 Gb以太网。类似地，在光网络环境中，最简单和最便宜的解决方案通常是通过选择更快的光载波或部署额外的lambda来提高光路径的数据速率。在带宽可以过度调配到损失或排队延迟可以忽略不计的地方，10:1过度调配通常是最便宜、最可靠的解决方案，顺便说一句，它为未来的需求提供了增长路径。然而，在通信网络中，有许多地方无法提供有效的无限带宽，包括许多接入网络、卫星通信、固定无线、机载和海上通信、岛屿连接以及与光纤连接不划算的地区的连接。正是在这些地方，资源管理的问题才是相关的。具体而言，我们不建议在超过100 MBPS的链路上部署重要的QoS程序，除了提供聚合服务外，聚合服务为网络的稳定性或实时流量的连续性提供特定保护，因为此类电路的数学不支持这一要求。
In short, the fact that we are discussing this class of policy control says that such constrictions in the network exist and must be dealt with. However much we might like to, in those places we are not solving the problem with bandwidth.
简言之，我们正在讨论这类政策控制的事实表明，网络中存在这种限制，必须加以处理。无论我们多么希望，在这些地方，我们并没有解决带宽问题。
A typical voice or video network, including a backbone domain, is shown in Figure 1.
典型的语音或视频网络，包括主干网域，如图1所示。
............... ......................
. . . .
. H H H H . . H H H H .
. /----------/ . . /----------/ .
. R SIP . . R R .
. \ . . / \ .
. R H H H . ....... / \ .
. /----------/ .. ../ R SIP .
. R .. /. /----------/ .
..... ..\. R-----R . H H H H .
...... .\ / \ . .
. \ / \ . .
. R-----------R ....................
. \ / .
. \ / .
. R-----R .
. .
............
............... ......................
. . . .
. H H H H . . H H H H .
. /----------/ . . /----------/ .
. R SIP . . R R .
. \ . . / \ .
. R H H H . ....... / \ .
. /----------/ .. ../ R SIP .
. R .. /. /----------/ .
..... ..\. R-----R . H H H H .
...... .\ / \ . .
. \ / \ . .
. R-----------R ....................
. \ / .
. \ / .
. R-----R .
. .
............
SIP = SIP Proxy
H = SIP-enabled Host (Telephone, call gateway or PC)
R = Router
/---/ = Ethernet or Ethernet Switch
SIP = SIP Proxy
H = SIP-enabled Host (Telephone, call gateway or PC)
R = Router
/---/ = Ethernet or Ethernet Switch
Figure 1: Typical VoIP or Video/IP Network
图1：典型的VoIP或视频/IP网络
Reviewing the figure above, it becomes obvious that Voice/IP and Video/IP call flows are very different than call flows in the PSTN. In the PSTN, call control traverses a switch, which in turn controls data handling services like ATM or Time Division Multiplexing (TDM) switches or multiplexers. While they may not be physically co-located, the control plane software and the data plane services are closely connected; the switch routes a call using bandwidth that it knows is available. In a voice/video-on-IP network, call control is completely divorced from the data plane: It is possible for a telephone instrument in the United States to have a Swedish telephone number if that is where its SIP proxy happens to be, but on any given call for it to use only data paths in the Asia/Pacific region, data paths provided by a different company, and, often, data paths provided by multiple companies/providers.
回顾上图，语音/IP和视频/IP呼叫流与PSTN中的呼叫流明显不同。在PSTN中，呼叫控制通过交换机，交换机反过来控制数据处理服务，如ATM或时分多路复用（TDM）交换机或多路复用器。虽然控制平面软件和数据平面服务在物理上可能不在同一位置，但它们紧密相连；交换机使用它知道可用的带宽路由呼叫。在IP语音/视频网络中，呼叫控制与数据平面完全分离：美国的电话设备可能有一个瑞典电话号码，如果它的SIP代理恰好在瑞典，但在任何给定的呼叫中，它只能使用亚太地区的数据路径，不同公司提供的数据路径，通常是多个公司/提供商提供的数据路径。
Call management therefore addresses a variety of questions, all of which must be answered:
因此，呼叫管理解决了各种各样的问题，所有这些问题都必须得到回答：
o May I make this call from an administrative policy perspective? Am I authorized to make this call?
o 我可以从行政政策的角度打这个电话吗？我有权打这个电话吗？
o What IP address correlates with this telephone number or SIP URI?
o 什么IP地址与此电话号码或SIP URI相关？
o Is the other instrument "on hook"? If it is busy, under what circumstances may I interrupt?
o 另一件乐器是“挂机”吗？如果很忙，在什么情况下我可以打断？
o Is there bandwidth available to support the call?
o 是否有可用带宽支持呼叫？
o Does the call actually work, or do other impairments (loss, delay) make the call unusable?
o 通话是否有效，或者其他损伤（丢失、延迟）是否导致通话无法使用？
Administrative Call Admission is the objective of SIP and H.323. It asks fundamental questions like "What IP address is the callee at?" and "Did you pay your bill?".
管理呼叫接纳是SIP和H.323的目标。它会问一些基本问题，比如“被叫人的IP地址是什么？”和“你付了账单了吗？”。
For a specialized policy like call preemption, two capabilities are necessary from an administrative perspective: [RFC4412] provides a way to communicate policy-related information regarding the precedence of the call; and [RFC4411] provides a reason code when a call fails or is refused, indicating the cause of the event. If it is a failure, it may make sense to redial the call. If it is a policy-driven preemption, even if the call is redialed it may not be possible to place the call. Requirements for this service are further discussed in [RFC3689].
对于像呼叫抢占这样的专门策略，从管理的角度来看，需要两种功能：[RFC4412]提供了一种方式来传递有关呼叫优先级的策略相关信息；[RFC4411]在呼叫失败或被拒绝时提供原因码，指示事件原因。如果出现故障，重拨电话可能有意义。如果是策略驱动的抢占，即使重拨了呼叫，也可能无法拨打。[RFC3689]中进一步讨论了该服务的要求。
The SIP Communications Resource Priority Header (or RP Header) serves the call setup process with the precedence level chosen by the initiator of the call. The syntax is in the form:
SIP通信资源优先级报头（或RP报头）以呼叫发起方选择的优先级为呼叫建立过程提供服务。语法的形式如下：
Resource Priority: namespace.priority level
资源优先级：namespace.Priority级别
The "namespace" part of the syntax ensures the domain of significance to the originator of the call, and this travels end-to-end to the destination (called) device (telephone). If the receiving phone does not support the namespace, it can easily ignore the setup request. This ability to denote the domain of origin allows Service Level Agreements (SLAs) to be in place to limit the ability of an unknown requester to gain preferential treatment into an IEPS domain.
语法中的“名称空间”部分确保了呼叫发起者所关注的领域，并将其端到端传输到目标（被叫）设备（电话）。如果接收电话不支持名称空间，它可以轻松忽略设置请求。这种表示来源域的能力允许制定服务级别协议（SLA），以限制未知请求者在IEPS域中获得优惠待遇的能力。
For the DSN infrastructure, the header would look like this for a routine precedence level call:
对于DSN基础结构，对于例程优先级调用，标头如下所示：
Resource Priority: dsn.routine
资源优先级：dsn.routine
The precedence level chosen in this header would be compared to the requester's authorization profile to use that precedence level. This would typically occur in the SIP first-hop Proxy, which can challenge many aspects of the call setup request including the requester's choice of precedence levels (verifying that they are not using a level they are not authorized to use).
此标头中选择的优先级别将与请求者的授权配置文件进行比较，以使用该优先级别。这通常会发生在SIP第一跳代理中，该代理可以质疑呼叫设置请求的许多方面，包括请求者选择的优先级别（验证他们没有使用未授权使用的级别）。
The DSN has 5 precedence levels of IEPS, in descending order:
DSN有5个IEP优先级，按降序排列：
dsn.flash-override
闪存覆盖
dsn.flash
闪光
dsn.immediate
直接
dsn.priority
优先权
dsn.routine
dsn.例行程序
The US Defense Red Switched Network (DRSN), as another example that was IANA-registered in [RFC4412], has 6 levels of precedence. The DRSN simply adds one precedence level higher than flash-override to be used by the President and a select few others:
美国国防红色交换网络（DRSN）作为IANA在[RFC4412]中注册的另一个示例，具有6个优先级。DRSN只是增加了一个比闪存覆盖更高的优先级，供总统和一些其他人使用：
drsn.flash-override-override
drsn.flash-override-override
Note that the namespace changed for this level. The lower 5 levels within the DRSN would also have this as their namespace for all DRSN-originated call setup requests.
请注意，此级别的命名空间已更改。DRSN中较低的5个级别也将该名称空间用作所有源自DRSN的呼叫设置请求的名称空间。
The Resource-Priority Header (RPH) informs both the use of Differentiated Services Code Points (DSCPs) by the callee (who needs to use the same DSCP as the caller to obtain the same data path service) and to facilitate policy-based preemption of calls in progress, when appropriate.
资源优先级报头（RPH）通知被呼叫方（需要使用与呼叫方相同的DSCP以获得相同的数据路径服务）对差异化服务代码点（DSCP）的使用，并在适当时促进基于策略的正在进行的呼叫抢占。
Once a call is established in an IEPS domain, the Reason Header for Preemption, described in [RFC4411], ensures that all SIP nodes are synchronized to a preemption event occurring either at the endpoint or in a router that experiences congestion. In SIP, the normal indication for the end of a session is for one end system to send a BYE Method request as specified in [RFC3261]. This, too, is the proper means for signaling a termination of a call due to a
一旦在IEPS域中建立呼叫，[RFC4411]中描述的抢占原因报头可确保所有SIP节点与发生在端点或遇到拥塞的路由器中的抢占事件同步。在SIP中，会话结束的正常指示是一个终端系统发送[RFC3261]中指定的BYE方法请求。这也是发出信号表示由于呼叫中断而终止呼叫的适当方式
preemption event, as it essentially performs a normal termination with additional information informing the peer of the reason for the abrupt end: it indicates that a preemption occurred. This will be used to inform all relevant SIP entities, and whether this was an endpoint-generated preemption event, or that the preemption event occurred within a router along the communications path (described in Section 2.3.1).
抢占事件，因为它本质上执行正常终止，并向对等方通知突然终止的原因：它表示发生了抢占。这将用于通知所有相关SIP实体，以及这是端点生成的抢占事件，还是抢占事件发生在沿通信路径的路由器内（如第2.3.1节所述）。
Figure 2 is a simple example of a SIP call setup that includes the layer 7 precedence of a call between Alice and Bob. After Alice successfully sets up a call to Bob at the "Routine" precedence level, Carol calls Bob at a higher precedence level (Immediate). At the SIP layer (this has nothing to do with RSVP yet; that example, involving SIP and RSVP signaling, is in the appendix), once Bob's user agent (phone) receives the INVITE message from Carol, his UA needs to make a choice between retaining the call to Alice and sending Carol a "busy" indication, or preempting the call to Alice in favor of accepting the call from Carol. That choice in IEPS networks is a comparison of Resource Priority headers. Alice, who controlled the precedence level of the call to Bob, sent the precedence level of her call to him at "Routine" (the lowest level within the network). Carol, who controls the priority of the call signal to Bob, sent her priority level to "Immediate" (higher than "Routine"). Bob's UA needs to (under IEPS policy) preempt the call from Alice (and provide her with a preemption indication in the call termination message). Bob needs to successfully answer the call setup from Carol.
图2是一个简单的SIP调用设置示例，其中包括Alice和Bob之间调用的第7层优先级。在Alice成功地在“例程”优先级级别设置对Bob的调用后，Carol在更高的优先级级别（立即）调用Bob。在SIP层（这与RSVP无关；该示例涉及SIP和RSVP信令，见附录），一旦Bob的用户代理（电话）接收到来自Carol的邀请消息，他的UA需要在保留对Alice的呼叫和向Carol发送“忙”指示之间做出选择，或者先打电话给爱丽丝，然后接受卡罗尔的电话。IEPS网络中的选择是比较资源优先级头。Alice控制了对Bob的呼叫优先级，并在“例程”（网络中的最低级别）向Bob发送了她的呼叫优先级。“呼叫优先级”高于“呼叫优先级”的“呼叫优先级”。Bob的UA需要（根据IEPS策略）抢占Alice的呼叫（并在呼叫终止消息中向她提供抢占指示）。Bob需要成功接听Carol的呼叫设置。
UA Alice UA Bob UA Carol
| INVITE (RP: Routine) | |
|--------------------------->| |
| 200 OK | |
|<---------------------------| |
| ACK | |
|--------------------------->| |
| RTP | |
|<==========================>| |
| | |
| | INVITE (RP: Immediate) |
| |<----------------------------|
| ************************************************ |
| *Resource Priority value comparison by Bob's UA* |
| ************************************************ |
| | |
| BYE (Reason: UA preemption) |
|<---------------------------| |
| | 200 OK |
| |---------------------------->|
| 200 OK (BYE) | |
|--------------------------->| |
| | ACK |
| |<----------------------------|
| | RTP |
| |<===========================>|
| | |
UA Alice UA Bob UA Carol
| INVITE (RP: Routine) | |
|--------------------------->| |
| 200 OK | |
|<---------------------------| |
| ACK | |
|--------------------------->| |
| RTP | |
|<==========================>| |
| | |
| | INVITE (RP: Immediate) |
| |<----------------------------|
| ************************************************ |
| *Resource Priority value comparison by Bob's UA* |
| ************************************************ |
| | |
| BYE (Reason: UA preemption) |
|<---------------------------| |
| | 200 OK |
| |---------------------------->|
| 200 OK (BYE) | |
|--------------------------->| |
| | ACK |
| |<----------------------------|
| | RTP |
| |<===========================>|
| | |
Figure 2: Priority Call Establishment and Termination at SIP Layer
图2:SIP层的优先级呼叫建立和终止
Nothing in this example involved mechanisms other than SIP. It is also assumed each user agent recognized the Resource-Priority header namespace value in each message. Therefore, it is assumed that the domain allowed Alice, Bob, and Carol to communicate. Authentication and Authorization are discussed later in this document.
本例中除了SIP之外，没有涉及其他机制。还假定每个用户代理都能识别每条消息中的资源优先级头命名空间值。因此，假定域允许Alice、Bob和Carol进行通信。本文档后面将讨论身份验证和授权。
The Quality of Service architecture used in the data path is that of [RFC2475]. Differentiated Services uses a flag in the IP header called the DSCP [RFC2474] to identify a data stream, and then applies a procedure called a Per Hop Behavior, or PHB, to it. This is largely as described in [RFC2998].
数据路径中使用的服务质量体系结构是[RFC2475]的体系结构。区分服务在IP报头中使用一个名为DSCP[RFC2474]的标志来标识数据流，然后对其应用一个称为每跳行为（PHB）的过程。这主要如[RFC2998]所述。
In the data path, the Expedited Forwarding PHB [RFC3246] [RFC3247] describes the fundamental needs of voice and video traffic. This PHB entails ensuring that sufficient bandwidth is dedicated to real-time traffic to ensure that variation in delay and loss rate are minimal,
在数据路径中，快速转发PHB[RFC3246][RFC3247]描述了语音和视频流量的基本需求。此PHB需要确保有足够的带宽专用于实时流量，以确保延迟和丢失率的变化最小，
as codecs are hampered by excessive loss [G711.1] [G711.3]. In parts of the network where bandwidth is heavily over-provisioned, there may be no remaining concern. In places in the network where bandwidth is more constrained, this may require the use of a priority queue. If a priority queue is used, the potential for abuse exists, meaning that it is also necessary to police traffic placed into the queue to detect and manage abuse. A fundamental question is "where does this policing need to take place?". The obvious places would be the first-hop routers and any place where converging data streams might congest a link.
由于编解码器受到过度损耗的阻碍[G711.1][G711.3]。在带宽严重过剩的部分网络中，可能没有剩余的问题。在带宽更受限的网络中，这可能需要使用优先级队列。如果使用优先级队列，则存在滥用的可能性，这意味着还需要对放入队列的流量进行监控，以检测和管理滥用。一个根本性的问题是“这种治安需要在哪里进行？”。显而易见的地方是第一跳路由器和任何汇聚数据流可能阻塞链路的地方。
Some proposals mark traffic with various code points appropriate to the service precedence of the call. In normal service, if the traffic is all in the same queue and EF service requirements are met (applied capacity exceeds offered load, variation in delay is minimal, and loss is negligible), details of traffic marking should be irrelevant, as long as packets get into the right service class. Then, the major issues are appropriate policing of traffic, especially around route changes, and ensuring that the path has sufficient capacity.
一些建议使用与呼叫的服务优先级相适应的各种代码点来标记通信量。在正常服务中，如果流量都在同一队列中，并且满足EF服务要求（应用容量超过提供的负载，延迟变化最小，损失可以忽略不计），只要数据包进入正确的服务类别，流量标记的细节就应该是不相关的。然后，主要问题是对交通进行适当的监管，特别是在路线变更周围，并确保道路具有足够的通行能力。
The real-time voice/video application should be generating traffic at a rate appropriate to its content and codec, which is either a constant bit rate stream or a stream whose rate is variable within a specified range. The first-hop router should be policing traffic originated by the application, as is performed in traditional virtual circuit networks like Frame Relay and ATM. Between these two checks (at what some networks call the Data Terminal Equipment (DTE) and Data Communications Equipment (DCE)), the application traffic should be guaranteed to be within acceptable limits. As such, given bandwidth-aware call admission control, there should be minimal actual loss. The cases where loss would occur include cases where routing has recently changed and CAC has not caught up, or cases where statistical thresholds are in use in CAC and the data streams happen to coincide at their peak rates.
实时语音/视频应用程序应以适合其内容和编解码器的速率生成流量，该速率为恒定比特率流或速率在指定范围内可变的流。第一跳路由器应该管理由应用程序发起的流量，就像在帧中继和ATM等传统虚拟电路网络中执行的那样。在这两次检查之间（某些网络称之为数据终端设备（DTE）和数据通信设备（DCE）），应保证应用程序流量在可接受的范围内。因此，给定带宽感知呼叫允许控制，实际损失应该最小。可能发生丢失的情况包括路由最近发生了变化而CAC没有赶上的情况，或者CAC中使用了统计阈值，并且数据流恰好以其峰值速率重合的情况。
If it is demonstrated that routing transients and variable rate beat frequencies present a sufficient problem, it is possible to provide a policing mechanism that isolates intentional loss among an ordered set of classes. While the ability to do so, by various algorithms, has been demonstrated, the technical requirement has not. If dropping random packets from all calls is not appropriate, concentrating random loss in a subset of the calls makes the problem for those calls worse; a superior approach would reject or preempt an entire call.
如果证明路由瞬变和可变速率拍频是一个足够的问题，那么就有可能提供一种在有序的类集合中隔离故意丢失的监管机制。虽然已经通过各种算法证明了这一能力，但技术要求尚未满足。如果从所有呼叫中丢弃随机数据包是不合适的，那么将随机丢失集中在呼叫子集中会使这些呼叫的问题变得更糟；高级方法会拒绝或抢占整个调用。
Parekh's second condition has been met: we must know what the network will do with the traffic. If the offered load exceeds the available
Parekh的第二个条件已经满足：我们必须知道网络将如何处理流量。如果提供的负载超过可用负载
bandwidth, the network will remark and drop the excess traffic. The key questions become "How does one limit offered load to a rate less than or equal to available bandwidth?" and "How much traffic does one admit with each appropriate marking?"
带宽，网络将记录并丢弃多余的流量。关键问题是“如何将提供的负载限制为小于或等于可用带宽的速率？”以及“每个适当的标记允许多少流量？”
Since many available voice and video codecs require a nominal loss rate to deliver acceptable performance, Parekh's first requirement is that offered load be within the available capacity. There are several possible approaches.
由于许多可用的语音和视频编解码器需要标称损耗率才能提供可接受的性能，Parekh的第一个要求是提供的负载必须在可用容量内。有几种可能的方法。
An approach that is commonly used in H.323 networks is to limit the number of calls simultaneously accepted by the gatekeeper. SIP networks do something similar when they place a stateful SIP proxy near a single ingress/egress to the network. This is able to impose an upper bound on the total number of calls in the network or the total number of calls crossing the significant link. However, the gatekeeper has no knowledge of routing, so the engineering must be very conservative and usually presumes a single ingress/egress or the failure of one of its data paths. While this may serve as a short-term work-around, it is not a general solution that is readily deployed. This limits the options in network design.
323网络中常用的一种方法是限制网守同时接受的呼叫数。当SIP网络在网络的单个入口/出口附近放置有状态SIP代理时，SIP网络也会做类似的事情。这能够对网络中的呼叫总数或通过有效链路的呼叫总数施加上限。然而，网守不知道路由，因此工程必须非常保守，并且通常假定一个入口/出口或其一条数据路径出现故障。虽然这可能是一个短期的解决方案，但它不是一个易于部署的通用解决方案。这限制了网络设计中的选项。
[RFC1633] provides for signaled admission for the use of capacity. The recommended approach is explicit capacity admission, supporting the concepts of preemption. An example of such a procedure uses the Resource Reservation Protocol [RFC2205] [RFC2209] (RSVP). The use of Capacity Admission using RSVP with SIP is described in [RFC3312]. While call counting is specified in H.323, network capacity admission is not integrated with H.323 at this time.
[RFC1633]提供了使用容量的信号许可。推荐的方法是显式容量接纳，支持抢占的概念。这种过程的示例使用资源保留协议[RFC2205][RFC2209]（RSVP）。[RFC3312]中描述了使用RSVP和SIP的容量许可的使用。虽然在H.323中指定了呼叫计数，但此时网络容量许可未与H.323集成。
2.3.1. RSVP Admission Using Policy for Both Unicast and Multicast Sessions
2.3.1. 使用单播和多播会话策略的RSVP接纳
RSVP is a resource reservation setup protocol providing the one-way (at a time) setup of resource reservations for multicast and unicast flows. Each reservation is set up in one direction (meaning one reservation from each end system; in a multicast environment, N senders set up N reservations). These reservations complete a communication path with a deterministic bandwidth allocation through each router along that path between end systems. These reservations set up a known quality of service for end-to-end communications and maintain a "soft-state" within a node. The meaning of the term "soft state" is that in the event of a network outage or change of routing, these reservations are cleared without manual intervention, but must be periodically refreshed. In RSVP, the refresh period is by default 30 seconds, but may be as long as is appropriate.
RSVP是一种资源预留设置协议，为多播和单播流提供单向（一次）资源预留设置。每个保留都是在一个方向上设置的（意味着来自每个终端系统的一个保留；在多播环境中，N个发送方设置N个保留）。这些保留完成了一条通信路径，通过终端系统之间的路径上的每个路由器进行确定性带宽分配。这些保留设置了端到端通信的已知服务质量，并在节点内保持“软状态”。术语“软状态”的含义是，在网络中断或路由改变的情况下，这些保留将在无需手动干预的情况下清除，但必须定期刷新。在RSVP中，默认情况下刷新周期为30秒，但只要合适，刷新周期可以尽可能长。
RSVP is a locally-oriented process, not a globally- or domain-oriented one like a routing protocol or H.323 Call Counting. Although it uses the local routing databases to determine the routing path, it is only concerned with the quality of service for a particular or aggregate flow through a device. RSVP is not aware of anything other than the local goal of QoS and its RSVP-enabled adjacencies, operating below the network layer. The process by itself neither requires nor has any end-to-end network knowledge or state. Thus, RSVP can be effective when it is enabled at some nodes in a network without the need to have every node participate.
RSVP是一个面向本地的过程，而不是像路由协议或H.323呼叫计数那样面向全局或域的过程。尽管它使用本地路由数据库来确定路由路径，但它只关心通过设备的特定或聚合流的服务质量。RSVP只知道QoS的本地目标及其支持RSVP的邻接，在网络层下运行。该过程本身既不需要也不具有任何端到端网络知识或状态。因此，当在网络中的某些节点启用RSVP时，RSVP可以有效，而不需要每个节点都参与。
HOST ROUTER
_____________________________ ____________________________
| _______ | | |
| | | _______ | | _______ |
| |Appli- | | | |RSVP | | | |
| | cation| | RSVP <---------------------------> RSVP <---------->
| | <--> | | | _______ | | |
| | | |process| _____ | ||Routing| |process| _____ |
| |_._____| | -->Policy| || <--> -->Policy||
| | |__.__._| |Cntrl|| ||process| |__.__._| |Cntrl||
| |data | | |_____|| ||__.____| | | |_____||
|===|===========|==|==========| |===|==========|==|==========|
| | --------| | _____ | | | --------| | _____ |
| | | | ---->Admis|| | | | | ---->Admis||
| _V__V_ ___V____ |Cntrl|| | _V__V_ __V_____ |Cntrl||
| | | | | |_____|| | | | | ||_____||
| |Class-| | Packet | | | |Class-| | Packet | |
| | ifier|==>Schedulr|================> ifier|==>Schedulr|=========>
| |______| |________| |data | |______| |________| data
| | | |
|_____________________________| |____________________________|
HOST ROUTER
_____________________________ ____________________________
| _______ | | |
| | | _______ | | _______ |
| |Appli- | | | |RSVP | | | |
| | cation| | RSVP <---------------------------> RSVP <---------->
| | <--> | | | _______ | | |
| | | |process| _____ | ||Routing| |process| _____ |
| |_._____| | -->Policy| || <--> -->Policy||
| | |__.__._| |Cntrl|| ||process| |__.__._| |Cntrl||
| |data | | |_____|| ||__.____| | | |_____||
|===|===========|==|==========| |===|==========|==|==========|
| | --------| | _____ | | | --------| | _____ |
| | | | ---->Admis|| | | | | ---->Admis||
| _V__V_ ___V____ |Cntrl|| | _V__V_ __V_____ |Cntrl||
| | | | | |_____|| | | | | ||_____||
| |Class-| | Packet | | | |Class-| | Packet | |
| | ifier|==>Schedulr|================> ifier|==>Schedulr|=========>
| |______| |________| |data | |______| |________| data
| | | |
|_____________________________| |____________________________|
Figure 3: RSVP in Hosts and Routers
图3：主机和路由器中的RSVP
Figure 3 shows the internal process of RSVP in both hosts (end systems) and routers, as shown in [RFC2209].
图3显示了主机（终端系统）和路由器中RSVP的内部过程，如[RFC2209]所示。
RSVP uses the phrase "traffic control" to describe the mechanisms of how a data flow receives quality of service. There are 3 different mechanisms to traffic control (shown in Figure 2 in both hosts and routers). They are:
RSVP使用短语“流量控制”来描述数据流如何接收服务质量的机制。流量控制有3种不同的机制（在主机和路由器中如图2所示）。他们是：
A packet classifier mechanism: This resolves the QoS class for each packet; this can determine the route as well.
一个包分类器机制：它为每个包解析QoS类；这也可以确定路线。
An admission control mechanism: This consists of two decision modules: admission control and policy control. Determining whether there are satisfactory resources for the requested QoS is the function of admission control. Determining whether the user has the authorization to request such resources is the function of policy control. If the parameters carried within this flow fail, either of these two modules errors the request using RSVP.
接纳控制机制：它由两个决策模块组成：接纳控制和策略控制。确定是否有满足所请求QoS的资源是接纳控制的功能。确定用户是否具有该策略控制该请求的功能。如果此流中携带的参数失败，则这两个模块中的任何一个都会使用RSVP发送错误请求。
A packet scheduler mechanism: At each outbound interface, the scheduler attains the guaranteed QoS for that flow.
数据包调度器机制：在每个出站接口上，调度器为该流实现有保证的QoS。
As originally written, there was concern that RSVP had scaling limitations due to its data plane behavior [RFC2208]. This either has not proven to be the case or has in time largely been corrected. Telephony services generally require peak call admission rates on the order of thousands of calls per minute and peak call levels comparable to the capacities of the lines in question, which is generally on the order of thousands to tens of thousands of calls. Current RSVP implementations admit calls at the rate of hundreds of calls per second and maintain as many calls in progress as memory configurations allow.
正如最初所写，由于RSVP的数据平面行为[RFC2208]，RSVP存在扩展限制。这要么没有被证明是事实，要么在时间上得到了很大的纠正。电话服务通常需要每分钟数千次呼叫的峰值呼叫接纳率，以及与相关线路容量相当的峰值呼叫水平，这通常需要数千至数万次呼叫。当前的RSVP实现以每秒数百个调用的速率允许调用，并在内存配置允许的情况下保持尽可能多的正在进行的调用。
In edge networks, RSVP is used to signal for individual microflows, admitting the bandwidth. However, Differentiated Services is used for the data plane behavior. Admission and policing may be performed anywhere, but need only be performed in the first-hop router (which, if the end system sending the traffic is a DTE, constitutes a DCE for the remaining network) and in routers that have interfaces threatened by congestion. In Figure 1, these would normally be the links that cross network boundaries.
在边缘网络中，RSVP用于为单个微流发送信号，允许带宽。但是，区分服务用于数据平面行为。准入和监管可以在任何地方执行，但只需要在第一跳路由器（如果发送流量的终端系统是DTE，则构成剩余网络的DCE）和具有受到拥塞威胁的接口的路由器中执行。在图1中，这些通常是跨越网络边界的链路。
In backbone networks, networks that are normally awash in bandwidth, RSVP and its affected data flows may be carried in a variety of ways. If the backbone is a maze of tunnels between its edges (true of MPLS networks, networks that carry traffic from an encryptor to a decryptor, and also VPNs), applicable technologies include [RFC2207], [RFC2746], and [RFC2983]. An IP tunnel is, simplistically put, a IP packet enveloped inside another IP packet as a payload. When IPv6 is transported over an IPv4 network, encapsulating the entire v6 packet inside a v4 packet is an effective means to accomplish this task. In this type of tunnel, the IPv6 packet is not read by any of the routers while inside the IPv4 envelope. If the inner packet is RSVP
在主干网中，通常带宽、RSVP及其受影响的数据流充斥的网络可能以多种方式承载。如果主干是其边缘之间的隧道迷宫（MPLS网络、将流量从加密机传输到解密机的网络以及VPN也是如此），则适用的技术包括[RFC2207]、[RFC2746]和[RFC2983]。简单地说，IP隧道是作为有效载荷封装在另一个IP包中的IP包。当IPv6通过IPv4网络传输时，将整个v6数据包封装在v4数据包中是完成此任务的有效方法。在这种类型的隧道中，任何路由器在IPv4信封内都不会读取IPv6数据包。如果内部数据包是RSVP
enabled, there must be an active configuration to ensure that all relevant backbone nodes read the RSVP fields; [RFC2746] describes this.
启用时，必须有一个活动配置，以确保所有相关主干节点读取RSVP字段；[RFC2746]对此进行了描述。
This is similar to how IPsec tunnels work. Encapsulating an RSVP packet inside an encrypted packet for security purposes without copying or conveying the RSVP indicators in the outside IP packet header would make RSVP inoperable while in this form of a tunnel. [RFC2207] describes how to modify an IPsec packet header to allow for RSVP awareness by nodes that need to provide QoS for the flow or flows inside a tunnel.
这类似于IPsec隧道的工作方式。出于安全目的，将RSVP数据包封装在加密数据包内，而不复制或传送外部IP数据包报头中的RSVP指示符，将使RSVP在这种隧道形式下不可操作。[RFC2207]描述如何修改IPsec数据包头，以允许需要为隧道内的流提供QoS的节点感知RSVP。
Other networks may simply choose to aggregate the reservations across themselves as described in [RFC3175]. The problem with an individual reservation architecture is that each flow requires a non-trivial amount of message exchange, computation, and memory resources in each router between each endpoint. Aggregation of flows reduces the number of completely individual reservations into groups of individual flows that can act as one for part or all of the journey between end systems. Aggregates are not intended to be from the first router to the last router within a flow, but to cover common paths of a large number of individual flows.
如[RFC3175]所述，其他网络可以简单地选择在其自身之间聚合预订。单个保留体系结构的问题是，每个流在每个端点之间的每个路由器中都需要大量的消息交换、计算和内存资源。流的聚合将完全独立的预订数量减少为一组独立的流，这些流可以作为终端系统之间部分或全部旅程的一个流。聚合的目的不是从流中的第一个路由器到最后一个路由器，而是覆盖大量单个流的公共路径。
Examples of aggregated data flows include streams of IP data that traverse common ingress and egress points in a network and also include tunnels of various kinds. MPLS LSPs, IPsec Security Associations between VPN edge routers, IP/IP tunnels, and Generic Routing Encapsulation (GRE) tunnels all fall into this general category. The distinguishing factor is that the system injecting an aggregate into the aggregated network sums the PATH and RESV statistical information on the un-aggregated side and produces a reservation for the tunnel on the aggregated side. If the bandwidth for the tunnel cannot be expanded, RSVP leaves the existing reservation in place and returns an error to the aggregator, which can then apply a policy such as IEPS to determine which session to refuse. In the data plane, the DSCP for the traffic must be copied from the inner to the outer header, to preserve the PHB's effect.
聚合数据流的示例包括穿过网络中的公共入口和出口点的IP数据流，还包括各种隧道。MPLS LSP、VPN边缘路由器之间的IPsec安全关联、IP/IP隧道和通用路由封装（GRE）隧道都属于这一类。区别因素是，将聚合注入聚合网络的系统将未聚合侧的路径和RESV统计信息相加，并在聚合侧为隧道生成保留。如果无法扩展隧道的带宽，RSVP将保留现有的保留，并向聚合器返回一个错误，然后聚合器可以应用诸如IEP之类的策略来确定拒绝哪个会话。在数据平面中，必须将流量的DSCP从内部头复制到外部头，以保持PHB的效果。
One concern with this approach is that this leaks information into the aggregated zone concerning the number of active calls or the bandwidth they consume. In fact, it does not, as the data itself is identifiable by aggregator address, deaggregator address, and DSCP. As such, even if it is not advertised, such information is measurable.
这种方法的一个问题是，这会将有关活动呼叫数或它们所消耗带宽的信息泄漏到聚合区域。事实上，它不是，因为数据本身可以通过聚合器地址、解聚合器地址和DSCP来识别。因此，即使没有广告，这些信息也是可测量的。
In the PATH message, the DCLASS object described in [RFC2996] is used to carry the determined DSCP for the precedence level of that call in the stream. This is reflected back in the RESV message. The DSCP will be determined from the authorized SIP message exchange between end systems by using the R-P header. The DCLASS object permits both bandwidth admission within a class and the building up of the various rates or token buckets.
在PATH消息中，[RFC2996]中描述的DCLASS对象用于携带流中该调用优先级的确定DSCP。这反映在RESV消息中。DSCP将通过使用R-P报头在终端系统之间的授权SIP消息交换来确定。DCLASS对象既允许类内的带宽许可，也允许建立各种速率或令牌桶。
RSVP's basic admission policy, as defined, is to grant any user bandwidth if there is bandwidth available within the current configuration. In other words, if a new request arrives and the difference between the configured upper bound and the currently reserved bandwidth is sufficiently large, RSVP grants use of that bandwidth. This basic policy may be augmented in various ways, such as using a local or remote policy engine to apply AAA procedures and further qualify the reservation.
根据定义，RSVP的基本许可策略是，如果当前配置中存在可用带宽，则授予任何用户带宽。换句话说，如果新请求到达，并且配置的上限和当前保留带宽之间的差异足够大，则RSVP允许使用该带宽。此基本策略可以通过各种方式进行扩展，例如使用本地或远程策略引擎应用AAA过程并进一步限定保留。
For certain applications, such as broadcast video using MPEG-1 or voice without activity detection and using a constant bit rate codec such as G.711, this basic policy is adequate apart from AAA. For variable rate codecs, such as MPEG-4 or a voice codec with Voice Activity Detection, however, this may be deemed too conservative. In such cases, two basic types of statistical policy have been studied and reported on in the literature: simple over-provisioning, and approximation to ambient load.
对于某些应用，例如使用MPEG-1的广播视频或无活动检测的语音，以及使用恒定比特率编解码器（如G.711），除了AAA之外，此基本策略是足够的。然而，对于可变速率编解码器，例如MPEG-4或具有语音活动检测的语音编解码器，这可能被认为过于保守。在这种情况下，文献中研究并报告了两种基本类型的统计策略：简单的过度配置和近似于环境负载。
Simple over-provisioning sets the bandwidth admission limit higher than the desired load, on the assumption that a session that admits a certain bandwidth will in fact use a fraction of the bandwidth. For example, if MPEG-4 data streams are known to use data rates between 80 and 800 KBPS and there is no obvious reason that sessions would synchronize (such as having commercial breaks on 15 minute boundaries), one could imagine estimating that the average session consumes 400 KBPS and treating an admission of 800 KBPS as actually consuming half the amount.
简单过度配置将带宽允许限制设置为高于所需负载，前提是允许特定带宽的会话实际上将使用带宽的一小部分。例如，如果已知MPEG-4数据流使用80到800 KBPS之间的数据速率，并且没有明显的原因使会话同步（例如在15分钟边界上有商业中断），可以想象，估计平均会话消耗400kbps，而将800kbps的接纳视为实际消耗量的一半。
One can also approximate to average load, which is perhaps a more reliable procedure. In this case, one maintains a variable that measures actual traffic through the admitted data's queue, approximating it using an exponentially weighted moving average. When a new reservation request arrives, if the requested rate is less than the difference between the configured upper bound and the
也可以近似于平均负载，这可能是更可靠的程序。在这种情况下，可以维护一个变量，该变量测量通过已接纳数据队列的实际流量，并使用指数加权移动平均值对其进行近似。当新的预订请求到达时，如果请求的速率小于配置的上限和
current value of the moving average, the reservation is accepted, and the moving average is immediately increased by the amount of the reservation to ensure that the bandwidth is not promised out to several users simultaneously. In time, the moving average will decay from this guard position to an estimate of true load, which may offer a chance to another session to be reserved that would otherwise have been refused.
移动平均值的当前值，接受保留，移动平均值立即增加保留量，以确保带宽不会同时承诺给多个用户。随着时间的推移，移动平均线将从这个保护位置衰减到真实负载的估计值，这可能会为另一个会话提供一个被保留的机会，否则该会话将被拒绝。
Statistical reservation schemes such as these are overwhelmingly dependent on the correctness of their configuration and its appropriateness for the codecs in use. However, they offer the opportunity to take advantage of statistical multiplexing gains that might otherwise be missed.
像这样的统计保留方案在很大程度上取决于其配置的正确性及其对所用编解码器的适用性。然而，它们提供了利用统计复用增益的机会，否则可能会错过这些增益。
2.3.5.2. Interaction with Complex Admission Policies, AAA, and Preemption of Bandwidth
2.3.5.2. 与复杂接纳策略、AAA和带宽抢占的交互
Policy is carried and applied as described in [RFC2753]. Figure 4, below, is the basic conceptual model for policy decisions and enforcement in an Integrated Services model. This model was created to provide the ability to monitor and control reservation flows based on user identify, specific traffic and security requirements, and conditions that might change for various reasons, including a reaction to a disaster or emergency event involving the network or its users.
按照[RFC2753]中的说明执行和应用策略。下图4是集成服务模型中策略决策和实施的基本概念模型。创建此模型是为了提供基于用户标识、特定流量和安全要求以及可能因各种原因而改变的条件（包括对涉及网络或其用户的灾难或紧急事件的反应）的监控和控制预订流的能力。
Network Node Policy server
______________
| ______ |
| | | | _____
| | PEP | | | |------------->
| |______|<---|---->| PDP |May use LDAP,SNMP,COPS...for accessing
| ^ | | | policy database, authentication, etc.
| | | |_____|------------->
| __v___ |
| | | | PDP = Policy Decision Point
| | LPDP | | PEP = Policy Enforcement Point
| |______| | LPDP = Local Policy Decision Point
|______________|
Network Node Policy server
______________
| ______ |
| | | | _____
| | PEP | | | |------------->
| |______|<---|---->| PDP |May use LDAP,SNMP,COPS...for accessing
| ^ | | | policy database, authentication, etc.
| | | |_____|------------->
| __v___ |
| | | | PDP = Policy Decision Point
| | LPDP | | PEP = Policy Enforcement Point
| |______| | LPDP = Local Policy Decision Point
|______________|
Figure 4: Conceptual Model for Policy Control of Routers
图4：路由器策略控制的概念模型
The Network Node represents a router in the network. The Policy Server represents the point of admission and policy control by the network operator. Policy Enforcement Point (PEP) (the router) is where the policy action is carried out. Policy decisions can be either locally present in the form of a Local Policy Decision Point (LPDP), or in a separate server on the network called the Policy
网络节点表示网络中的路由器。策略服务器代表网络运营商的准入点和策略控制点。策略执行点（PEP）（路由器）是执行策略操作的地方。策略决策可以以本地策略决策点（LPDP）的形式在本地显示，也可以在网络上称为策略的单独服务器中显示
Decision Point. The easier the instruction set of rules, the more likely this set can reside in the LPDP for speed of access reasons. The more complex the rule set, the more likely this is active on a remote server. The PDP will use other protocols (LDAP, SNMP, etc.) to request information (e.g., user authentication and authorization for precedence level usage) to be used in creating the rule sets of network components. This remote PDP should also be considered where non-reactive policies are distributed out to the LPDPs.
决策点。规则的指令集越简单，出于访问速度的原因，该指令集就越有可能驻留在LPDP中。规则集越复杂，就越有可能在远程服务器上处于活动状态。PDP将使用其他协议（LDAP、SNMP等）请求在创建网络组件规则集时使用的信息（例如，优先级别使用的用户身份验证和授权）。如果将非反应性策略分发给LPDP，也应考虑此远程PDP。
Taking the above model as a framework, [RFC2750] extends RSVP's concept of a simple reservation to include policy controls, including the concepts of Preemption [RFC3181] and Identity [RFC3182], specifically speaking to the usage of policies that preempt calls under the control of either a local or remote policy manager. The policy manager assigns a precedence level to the admitted data flow. If it admits a data flow that exceeds the available capacity of a system, the expectation is that the RSVP-affected RSVP process will tear down a session among the lowest precedence sessions it has admitted. The RESV Error resulting from that will go to the receiver of the data flow and be reported to the application (SIP or H.323). That application is responsible for disconnecting its call, with a reason code of "bandwidth preemption".
以上述模型为框架，[RFC2750]扩展了RSVP的简单保留概念，以包括策略控制，包括抢占[RFC3181]和标识[RFC3182]的概念，具体来说是指在本地或远程策略管理器的控制下抢占呼叫的策略的使用。策略管理器为允许的数据流分配优先级。如果它允许的数据流超过了系统的可用容量，则预期受RSVP影响的RSVP进程将中断它所允许的最低优先级会话中的一个会话。由此产生的RESV错误将发送到数据流的接收器并报告给应用程序（SIP或H.323）。该应用程序负责断开其呼叫，原因码为“带宽抢占”。
It will be necessary, of course, to ensure that any policy is applied to an authenticated user; the capabilities assigned to an authenticated user may be considered authorized for use in the network. For bandwidth admission, this will require the utilization of [RFC2747] [RFC3097]. In SIP and H.323, AAA procedures will also be needed.
当然，有必要确保将任何策略应用于经过身份验证的用户；分配给认证用户的能力可被视为授权在网络中使用。对于带宽许可，这将需要使用[RFC2747][RFC3097]。在SIP和H.323中，还需要AAA程序。
The user interface -- the chimes and tones heard by the user -- should ideally remain the same as in the PSTN for those indications that are still applicable to an IP network. There should be some new effort generated to update the list of announcements sent to the user that don't necessarily apply. All indications to the user, of course, depend on positive signals, not unreliable measures based on changing measurements.
对于仍然适用于IP网络的指示，用户界面（用户听到的蜂鸣音和铃声）理想情况下应保持与PSTN中相同。应该有一些新的努力来更新发送给用户的通知列表，这些通知不一定适用。当然，向用户提供的所有指示都取决于积极信号，而不是基于测量值变化的不可靠测量值。
This document outlines a networking capability composed entirely of existing specifications. It has significant security issues, in the sense that a failure of the various authentication or authorization procedures can cause a fundamental breakdown in communications. However, the issues are internal to the various component protocols and are covered by their various security procedures.
本文档概述了完全由现有规范组成的网络功能。它有重大的安全问题，因为各种身份验证或授权程序的失败可能会导致通信的根本中断。但是，这些问题是各种组件协议的内部问题，并由其各种安全程序涵盖。
This document was developed with the knowledge and input of many people, far too numerous to be mentioned by name. However, key contributors of thoughts include Francois Le Faucheur, Haluk Keskiner, Rohan Mahy, Scott Bradner, Scott Morrison, Subha Dhesikan, and Tony De Simone. Pete Babendreier, Ken Carlberg, and Mike Pierce provided useful reviews.
这份文件是在许多人的知识和投入下编写的，其数量之多，名不副实。然而，思想的主要贡献者包括弗朗索瓦·勒·福彻、哈卢克·凯斯基纳、罗汉·马伊、斯科特·布拉德纳、斯科特·莫里森、苏巴·德西坎和托尼·德·西蒙尼。皮特·巴本德雷尔、肯·卡尔伯格和迈克·皮尔斯提供了有用的评论。
[RFC3689] Carlberg, K. and R. Atkinson, "General Requirements for Emergency Telecommunication Service (ETS)", RFC 3689, February 2004.
[RFC3689]Carlberg，K.和R.Atkinson，“紧急电信服务（ETS）的一般要求”，RFC 3689，2004年2月。
[RFC3690] Carlberg, K. and R. Atkinson, "IP Telephony Requirements for Emergency Telecommunication Service (ETS)", RFC 3690, February 2004.
[RFC3690]Carlberg，K.和R.Atkinson，“紧急电信服务（ETS）的IP电话要求”，RFC 36902004年2月。
Integrated Services Architecture References
综合服务体系结构参考
[RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994.
[RFC1633]Braden，B.，Clark，D.，和S.Shenker，“互联网体系结构中的综合服务：概述”，RFC163331994年6月。
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205]Braden，B.，Zhang，L.，Berson，S.，Herzog，S.，和S.Jamin，“资源预留协议（RSVP）——第1版功能规范”，RFC 22052997年9月。
[RFC2207] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC Data Flows", RFC 2207, September 1997.
[RFC2207]Berger，L.和T.O'Malley，“IPSEC数据流的RSVP扩展”，RFC 2207，1997年9月。
[RFC2208] Mankin, A., Baker, F., Braden, B., Bradner, S., O'Dell, M., Romanow, A., Weinrib, A., and L. Zhang, "Resource ReSerVation Protocol (RSVP) Version 1 Applicability Statement Some Guidelines on Deployment", RFC 2208, September 1997.
[RFC2208]Mankin，A.，Baker，F.，Braden，B.，Bradner，S.，O'Dell，M.，Romanow，A.，Weinrib，A.，和L.Zhang，“资源保留协议（RSVP）第1版适用性声明—关于部署的一些指南”，RFC 2208，1997年9月。
[RFC2209] Braden, B. and L. Zhang, "Resource ReSerVation Protocol (RSVP) -- Version 1 Message Processing Rules", RFC 2209, September 1997.
[RFC2209]Braden，B.和L.Zhang，“资源预留协议（RSVP）——第1版消息处理规则”，RFC 2209，1997年9月。
[RFC2746] Terzis, A., Krawczyk, J., Wroclawski, J., and L. Zhang, "RSVP Operation Over IP Tunnels", RFC 2746, January 2000.
[RFC2746]Terzis，A.，Krawczyk，J.，Wroclawski，J.，和L.Zhang，“IP隧道上的RSVP操作”，RFC 2746，2000年1月。
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000.
[RFC2747]Baker，F.，Lindell，B.和M.Talwar，“RSVP加密认证”，RFC 2747，2000年1月。
[RFC2750] Herzog, S., "RSVP Extensions for Policy Control", RFC 2750, January 2000.
[RFC2750]Herzog，S.，“策略控制的RSVP扩展”，RFC 2750，2000年1月。
[RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework for Policy-based Admission Control", RFC 2753, January 2000.
[RFC2753]Yavatkar，R.，Pendarakis，D.，和R.Guerin，“基于政策的准入控制框架”，RFC 2753，2000年1月。
[RFC2996] Bernet, Y., "Format of the RSVP DCLASS Object", RFC 2996, November 2000.
[RFC2996]Bernet，Y.，“RSVP数据类对象的格式”，RFC 2996，2000年11月。
[RFC2998] Bernet, Y., Ford, P., Yavatkar, R., Baker, F., Zhang, L., Speer, M., Braden, R., Davie, B., Wroclawski, J., and E. Felstaine, "A Framework for Integrated Services Operation over Diffserv Networks", RFC 2998, November 2000.
[RFC2998]Bernet，Y.，Ford，P.，Yavatkar，R.，Baker，F.，Zhang，L.，Speer，M.，Braden，R.，Davie，B.，Wroclawski，J.，和E.Felstaine，“区分服务网络上的综合服务运营框架”，RFC 2998，2000年11月。
[RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic Authentication -- Updated Message Type Value", RFC 3097, April 2001.
[RFC3097]Braden，R.和L.Zhang，“RSVP加密身份验证——更新的消息类型值”，RFC 3097，2001年4月。
[RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175, September 2001.
[RFC3175]Baker，F.，Iturralde，C.，Le Faucheur，F.，和B.Davie，“IPv4和IPv6保留的RSVP聚合”，RFC 3175，2001年9月。
[RFC3181] Herzog, S., "Signaled Preemption Priority Policy Element", RFC 3181, October 2001.
[RFC3181]Herzog，S.，“信号抢占优先权政策要素”，RFC 31812001年10月。
[RFC3182] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T., Herzog, S., and R. Hess, "Identity Representation for RSVP", RFC 3182, October 2001.
[RFC3182]Yadav，S.，Yavatkar，R.，Pabbati，R.，Ford，P.，Moore，T.，Herzog，S.，和R.Hess，“RSVP的身份表示”，RFC 31822001年10月。
[RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg, "Integration of Resource Management and Session Initiation Protocol (SIP)", RFC 3312, October 2002.
[RFC3312]Camarillo，G.，Marshall，W.，和J.Rosenberg，“资源管理和会话启动协议（SIP）的集成”，RFC 3312，2002年10月。
Differentiated Services Architecture References
区分服务体系结构参考
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[RFC2474]Nichols，K.，Blake，S.，Baker，F.，和D.Black，“IPv4和IPv6头中区分服务字段（DS字段）的定义”，RFC 2474，1998年12月。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
[RFC2475]Blake，S.，Black，D.，Carlson，M.，Davies，E.，Wang，Z.，和W.Weiss，“差异化服务架构”，RFC 24751998年12月。
[RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 2983, October 2000.
[RFC2983]Black，D.，“差异化服务和隧道”，RFC 29832000年10月。
[RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, J., Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002.
[RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, J., Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002.translate error, please retry
[RFC3247] Charny, A., Bennet, J., Benson, K., Boudec, J., Chiu, A., Courtney, W., Davari, S., Firoiu, V., Kalmanek, C., and K. Ramakrishnan, "Supplemental Information for the New Definition of the EF PHB (Expedited Forwarding Per-Hop Behavior)", RFC 3247, March 2002.
[RFC3247]Charny，A.，Bennet，J.，Benson，K.，Boudec，J.，Chiu，A.，Courtney，W.，Davari，S.，Firoiu，V.，Kalmanek，C.，和K.Ramakrishnan，“EF PHB（每跳快速转发行为）新定义的补充信息”，RFC 3247，2002年3月。
Session Initiation Protocol and Related References
会话启动协议及相关参考文献
[RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[RFC2327]Handley，M.和V.Jacobson，“SDP：会话描述协议”，RFC 2327，1998年4月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[RFC4411] Polk, J., "Extending the Session Initiation Protocol (SIP) Reason Header for Preemption Events", RFC 4411, February 2006.
[RFC4411]Polk，J.“扩展抢占事件的会话启动协议（SIP）原因头”，RFC 4411，2006年2月。
[RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource Priority for the Session Initiation Protocol (SIP)", RFC 4412, February 2006.
[RFC4412]Schulzrinne，H.和J.Polk，“会话启动协议（SIP）的通信资源优先级”，RFC 4412，2006年2月。
[ANSI.MLPP.Spec] American National Standards Institute, "Telecommunications - Integrated Services Digital Network (ISDN) - Multi-Level Precedence and Preemption (MLPP) Service Capability", ANSI T1.619-1992 (R1999), 1992.
[ANSI.MLPP.Spec]美国国家标准协会，“电信-综合业务数字网（ISDN）-多级优先和抢占（MLPP）服务能力”，ANSI T1.619-1992（R1999），1992年。
[ANSI.MLPP.Supp] American National Standards Institute, "MLPP Service Domain Cause Value Changes", ANSI ANSI T1.619a-1994 (R1999), 1990.
[ANSI.MLPP.Supp]美国国家标准协会，“MLPP服务域导致值变化”，ANSI ANSI T1.619a-1994（R1999），1990年。
[G711.1] Viola Networks, "Netally VoIP Evaluator", January 2003, <http://www.brainworks.de/Site/hersteller/ viola_networks/Dokumente/Compr_Report_Sample.pdf>.
[G711.1]Viola Networks，“Netally VoIP Evaluator”，2003年1月<http://www.brainworks.de/Site/hersteller/ viola\u networks/Dokumente/Compr\u Report\u Sample.pdf>。
[G711.3] Nortel Networks, "Packet Loss and Packet Loss Concealment", 2000, <http://www.nortelnetworks.com/ products/01/succession/es/collateral/ tb_pktloss.pdf>.
[G711.3]北电网络，“数据包丢失和数据包丢失隐藏”，2000年<http://www.nortelnetworks.com/ products/01/Sequence/es/collateral/tb_pktloss.pdf>。
[ITU.ETS.E106] International Telecommunications Union, "International Emergency Preference Scheme for disaster relief operations (IEPS)", ITU-T Recommendation E.106, October 2003.
[ITU.ETS.E106]国际电信联盟，“国际救灾行动应急优先计划（IEP）”，ITU-T建议E.106，2003年10月。
[ITU.MLPP.1990] International Telecommunications Union, "Multilevel Precedence and Preemption Service (MLPP)", ITU-T Recommendation I.255.3, 1990.
[ITU.MLPP.1990]国际电信联盟，“多级优先和抢占服务（MLPP）”，ITU-T建议I.255.31990。
[Parekh1] Parekh, A. and R. Gallager, "A Generalized Processor Sharing Approach to Flow Control in Integrated Services Networks: The Multiple Node Case", INFOCOM 1993: 521-530, 1993.
[Parekh1]Parekh，A.和R.Gallager，“综合业务网络中流量控制的广义处理器共享方法：多节点案例”，INFOCOM 1993:521-530，1993。
[Parekh2] Parekh, A. and R. Gallager, "A Generalized Processor Sharing Approach to Flow Control in Integrated Services Networks: The Single Node Case", INFOCOM 1992: 915-924, 1992.
[Parekh2]Parekh，A.和R.Gallager，“综合业务网络中流量控制的广义处理器共享方法：单节点案例”，INFOCOM 1992:915-9242992。
This appendix will present a more complete view of the interaction among SIP, SDP, and RSVP. The bulk of the material is referenced from [RFC2327], [RFC3312], [RFC4411], and [RFC4412]. There will be some discussion on basic RSVP operations regarding reservation paths; this will be mostly from [RFC2205].
本附录将提供SIP、SDP和RSVP之间交互的更完整视图。大部分材料参考[RFC2327]、[RFC3312]、[RFC4411]和[RFC4412]。将讨论有关保留路径的基本RSVP操作；这将主要来自[RFC2205]。
SIP signaling occurs at the Application Layer, riding on a UDP/IP or TCP/IP (including TLS/TCP/IP) transport that is bound by routing protocols such as BGP and OSPF to determine the route the packets traverse through a network between source and destination devices. RSVP is riding on top of IP as well, which means RSVP is at the mercy of the IP routing protocols to determine a path through the network between endpoints. RSVP is not a routing protocol. In this appendix, there will be an escalation of building blocks getting to how the many layers are involved in SIP. QoS Preconditions require successful RSVP signaling between endpoints prior to SIP successfully acknowledging the setup of the session (for voice, video, or both). Then we will present what occurs when a network overload occurs (congestion), causing a SIP session to be preempted.
SIP信令发生在应用层，通过UDP/IP或TCP/IP（包括TLS/TCP/IP）传输，该传输由路由协议（如BGP和OSPF）绑定，以确定数据包在源设备和目标设备之间通过网络的路由。RSVP也位于IP之上，这意味着RSVP受IP路由协议的支配，以确定端点之间通过网络的路径。RSVP不是路由协议。在本附录中，将逐步升级构建块，以了解SIP涉及多少层。QoS先决条件要求在SIP成功确认会话设置（对于语音、视频或两者）之前，在端点之间成功发送RSVP信令。然后，我们将介绍当网络过载（拥塞）导致SIP会话被抢占时发生的情况。
Three diagrams in this appendix show multiple views of the same example of connectivity for discussion throughout this appendix. The first diagram (Figure 5) is of many routers between many endpoints (SIP user agents, or UAs). There are 4 UAs of interest; those are for users Alice, Bob, Carol, and Dave. When a user (the human) of a UA gets involved and must do something to a UA to progress a SIP process, this will be explicitly mentioned to avoid confusion; otherwise, when Alice is referred to, it means Alice's UA (her phone).
本附录中的三个图表显示了相同连接示例的多个视图，供本附录讨论。第一个图（图5）是许多端点（SIP用户代理或UAs）之间的许多路由器。有4个感兴趣的无人机；这些是为用户Alice、Bob、Carol和Dave准备的。当UA的用户（人）参与进来并且必须对UA做一些事情来推进SIP过程时，将明确提及这一点以避免混淆；否则，当提到Alice时，它意味着Alice的UA（她的手机）。
RSVP reserves bandwidth in one direction only (the direction of the RESV message), as has been discussed, IP forwarding of packets are dictated by the routing protocol for that portion of the infrastructure from the point of view of where the packet is to go next.
RSVP仅在一个方向（RESV消息的方向）上保留带宽，如前所述，数据包的IP转发由基础设施该部分的路由协议从数据包下一步要去哪里的角度决定。
The RESV message traverses the routers in the reverse path taken by the PATH message. The PATH message establishes a record of the route taken through a network portion to the destination endpoint, but it does not reserve resources (bandwidth). The RESV message back to the original requester of the RSVP flow requests for the bandwidth resources. This means the endpoint that initiates the RESV message controls the parameters of the reservation. This document specifies in the body text that the SIP initiator (the UAC) establishes the parameters of the session in an INVITE message, and that the INVITE recipient (the UAS) must follow the parameters established in that
RESV消息以path消息采用的反向路径遍历路由器。PATH消息建立了通过网络部分到目标端点的路由记录，但它不保留资源（带宽）。RESV消息返回到RSVP流的原始请求者，请求带宽资源。这意味着发起RESV消息的端点控制保留的参数。本文档在正文中指定SIP发起方（UAC）在INVITE消息中建立会话参数，并且INVITE接收方（UAS）必须遵循该消息中建立的参数
INVITE message. One exception to this is which codec to use if the UAC offered more than one to the UAS. This exception will be shown when the INVITE message is discussed in detail later in the appendix. If there was only one codec in the SDP of the INVITE message, the parameters of the reservation will follow what the UAC requested (specifically to include the Resource-Priority header namespace and priority value).
邀请消息。一个例外是，如果UAC向UAS提供多个编解码器，则应使用哪个编解码器。在附录后面详细讨论邀请消息时，将显示此异常。如果INVITE消息的SDP中只有一个编解码器，则保留的参数将遵循UAC的请求（特别是包括资源优先级头名称空间和优先级值）。
Here is the first figure with the 4 UAs and a meshed routed infrastructure between each. For simplicity of this explanation, this appendix will only discuss the reservations from Alice to Bob (one direction) and from Carol to Dave (one direction). An interactive voice service will require two one-way reservations that end in each UA. This gives the appearance of a two-way reservation, when indeed it is not.
这是第一个图，其中有4个UAs，每个UAs之间有一个网状路由基础设施。为了便于解释，本附录仅讨论从Alice到Bob（单向）和从Carol到Dave（单向）的预订。交互式语音服务将需要两个单向预订，以每个UA结束。这似乎是一种双向保留，但实际上并非如此。
Alice -----R1----R2----R3----R4------ Bob
| \ / \ / \ / |
| \/ \/ \/ |
| /\ /\ /\ |
| / \ / \ / \ |
Carol -----R5----R6----R7----R8------ Dave
Alice -----R1----R2----R3----R4------ Bob
| \ / \ / \ / |
| \/ \/ \/ |
| /\ /\ /\ |
| / \ / \ / \ |
Carol -----R5----R6----R7----R8------ Dave
Figure 5: Complex Routing and Reservation Topology
图5：复杂的路由和保留拓扑
The PATH message from Alice to Bob (establishing the route for the RESV message) will be through routers:
从Alice到Bob的路径消息（为RESV消息建立路由）将通过路由器：
Alice -> R1 -> R2 -> R3 -> R4 -> Bob
Alice -> R1 -> R2 -> R3 -> R4 -> Bob
The RESV message (and therefore the reservation of resources) from Bob to Alice will be through routers:
从Bob到Alice的RESV消息（以及资源预留）将通过路由器：
Bob -> R4 -> R3 -> R2 -> R1 -> Alice
Bob -> R4 -> R3 -> R2 -> R1 -> Alice
The PATH message from Carol to Dave (establishing the route for the RESV message) will be through routers:
从Carol到Dave的路径消息（为RESV消息建立路由）将通过路由器：
Carol -> R5 -> R2 -> R3 -> R8 -> Dave
Carol -> R5 -> R2 -> R3 -> R8 -> Dave
The RESV message (and therefore the reservation of resources) from Dave to Carol will be through routers:
从Dave到Carol的RESV消息（以及资源预订）将通过路由器：
Dave -> R8 -> R3 -> R2 -> R5 -> Carol
Dave -> R8 -> R3 -> R2 -> R5 -> Carol
The reservations from Alice to Bob traverse a common router link: between R3 and R2 and thus a common interface at R2. Here is where there will be congestion in this example, on the link between R2 and
从Alice到Bob的保留穿越了一个公共路由器链路：在R3和R2之间，因此在R2上有一个公共接口。在本例中，R2和R2之间的链路将出现拥塞
R3. Since the flow of data (in this case voice media packets) travels the direction of the PATH message, and RSVP establishes reservation of resources at the egress interface of a router, the interface in Figure 6 shows that Int7 will be what first knows about a congestion condition.
R3。由于数据流（在本例中为语音媒体包）沿着路径消息的方向移动，并且RSVP在路由器的出口接口处建立资源保留，因此图6中的接口显示Int7将是首先知道拥塞情况的。
Alice Bob
\ /
\ /
+--------+ +--------+
| | | |
| R2 | | R3 |
| Int7-------Int5 |
| | | |
+--------+ +--------+
/ \
/ \
Carol Dave
Alice Bob
\ /
\ /
+--------+ +--------+
| | | |
| R2 | | R3 |
| Int7-------Int5 |
| | | |
+--------+ +--------+
/ \
/ \
Carol Dave
Figure 6: Reduced Reservation Topology
图6：简化的保留拓扑
Figure 6 illustrates how the messaging between the UAs and the RSVP messages between the relevant routers can be shown to understand the binding that was established in [RFC3312] (more suitably titled "SIP Preconditions for QoS" from this document's point of view).
图6说明了如何显示UAs之间的消息传递和相关路由器之间的RSVP消息，以理解[RFC3312]中建立的绑定（从本文档的角度来看，更合适地称为“QoS的SIP先决条件”）。
We will assume all devices have powered up and received whatever registration or remote policy downloads were necessary for proper operation. The routing protocol of choice has performed its routing table update throughout this part of the network. Now we are left to focus only on end-to-end communications and how that affects the infrastructure between endpoints.
我们将假设所有设备都已通电，并已收到正确操作所需的任何注册或远程策略下载。选择的路由协议已在网络的这一部分执行路由表更新。现在，我们只关注端到端通信以及它如何影响端点之间的基础设施。
The next diagram (Figure 7) (nearly identical to Figure 1 from [RFC3312]) shows the minimum SIP messaging (at layer 7) between Alice and Bob for a good-quality voice call. The SIP messages are numbered to identify special qualities of each. During the SIP signaling, RSVP will be initiated. That messaging will also be discussed below.
下一个图（图7）（与[RFC3312]中的图1几乎相同）显示了Alice和Bob之间的最小SIP消息传递（在第7层），以实现高质量的语音呼叫。SIP消息被编号以识别每个消息的特殊性质。在SIP信令期间，将启动RSVP。下面还将讨论该消息传递。
UA Alice UA Bob
| |
| |
|-------------(1) INVITE SDP1--------------->|
| | Note 1
|<------(2) 183 Session Progress SDP2--------| |
***|********************************************|***<-+
* |----------------(3) PRACK------------------>| *
* | | * Where
* |<-----------(4) 200 OK (PRACK)--------------| * RSVP
* | | * is
* | | * signaled
***|********************************************|***
|-------------(5) UPDATE SDP3--------------->|
| |
|<--------(6) 200 OK (UPDATE) SDP4-----------|
| |
|<-------------(7) 180 Ringing---------------|
| |
|-----------------(8) PRACK----------------->|
| |
|<------------(9) 200 OK (PRACK)-------------|
| |
| |
|<-----------(10) 200 OK (INVITE)------------|
| |
|------------------(11) ACK----------------->|
| |
| RTP (within the reservation) |
|<==========================================>|
| |
UA Alice UA Bob
| |
| |
|-------------(1) INVITE SDP1--------------->|
| | Note 1
|<------(2) 183 Session Progress SDP2--------| |
***|********************************************|***<-+
* |----------------(3) PRACK------------------>| *
* | | * Where
* |<-----------(4) 200 OK (PRACK)--------------| * RSVP
* | | * is
* | | * signaled
***|********************************************|***
|-------------(5) UPDATE SDP3--------------->|
| |
|<--------(6) 200 OK (UPDATE) SDP4-----------|
| |
|<-------------(7) 180 Ringing---------------|
| |
|-----------------(8) PRACK----------------->|
| |
|<------------(9) 200 OK (PRACK)-------------|
| |
| |
|<-----------(10) 200 OK (INVITE)------------|
| |
|------------------(11) ACK----------------->|
| |
| RTP (within the reservation) |
|<==========================================>|
| |
Figure 7: SIP Reservation Establishment Using Preconditions
图7：使用先决条件建立SIP预约
The session initiation starts with Alice wanting to communicate with Bob. Alice decides on an IEPS precedence level for their call (the default is the "routine" level, which is for normal everyday calls, but a priority level has to be chosen for each call). Alice puts into her UA Bob's address and precedence level and (effectively) hits the send button. This is reflected in SIP with an INVITE Method Request message [M1]. Below is what SIP folks call a well-formed SIP message (meaning it has all the headers that are mandatory to function properly). We will pick on the US Marine Corps (USMC) for the addressing of this message exchange.
会话启动从Alice想要与Bob通信开始。Alice决定其调用的IEPS优先级（默认为“例程”级别，这是用于正常的日常调用，但必须为每个调用选择优先级）。Alice输入UA Bob的地址和优先级，然后（有效地）点击发送按钮。这反映在SIP中，其中包含INVITE方法请求消息[M1]。下面是SIP人员所称的格式良好的SIP消息（意味着它具有所有必须正常运行的头）。我们将挑选美国海军陆战队（USMC）来处理此消息交换。
[M1 - INVITE from Alice to Bob, RP=Routine, QOS=e2e and mandatory]
INVITE sip:bob@usmc.example.mil SIP/2.0
Via: SIP/2.0/TCP pc33.usmc.example.mil:5060
;branch=z9hG4bK74bf9
Max-Forwards: 70
From: Alice <sip:alice@usmc.example.mil>;tag=9fxced76sl
To: Bob <sip:bob@usmc.example.mil>
Call-ID: 3848276298220188511@pc33.usmc.example.mil
CSeq: 31862 INVITE
Require: 100rel, preconditions, resource-priority
Resource-Priority: dsn.routine
Contact: <sip:alice@usmc.example.mil>
Content-Type: application/sdp
Content-Length: 191
[M1 - INVITE from Alice to Bob, RP=Routine, QOS=e2e and mandatory]
INVITE sip:bob@usmc.example.mil SIP/2.0
Via: SIP/2.0/TCP pc33.usmc.example.mil:5060
;branch=z9hG4bK74bf9
Max-Forwards: 70
From: Alice <sip:alice@usmc.example.mil>;tag=9fxced76sl
To: Bob <sip:bob@usmc.example.mil>
Call-ID: 3848276298220188511@pc33.usmc.example.mil
CSeq: 31862 INVITE
Require: 100rel, preconditions, resource-priority
Resource-Priority: dsn.routine
Contact: <sip:alice@usmc.example.mil>
Content-Type: application/sdp
Content-Length: 191
v=0
o=alice 2890844526 2890844526 IN IP4 usmc.example.mil
c=IN IP4 10.1.3.33
t=0 0
m=audio 49172 RTP/AVP 0 4 8
a=rtpmap:0 PCMU/8000
a=curr:qos e2e none
a=des:qos mandatory e2e sendrecv
v=0
o=alice 2890844526 2890844526 IN IP4 usmc.example.mil
c=IN IP4 10.1.3.33
t=0 0
m=audio 49172 RTP/AVP 0 4 8
a=rtpmap:0 PCMU/8000
a=curr:qos e2e none
a=des:qos mandatory e2e sendrecv
From the INVITE above, Alice is inviting Bob to a session. The upper half of the lines (above the line "v=0") is SIP headers and header values, and the lower half is Session Description Protocol (SDP) lines. SIP headers (after the first line, called the Status line) are not mandated in any particular order, with one exception: the Via header. It is a SIP hop (through a SIP Proxy) route path that has a new Via header line added by each SIP element this message traverses towards the destination UA. This is similar in function to an RSVP PATH message (building a reverse path back to the originator of the message). At any point in the message's path, a SIP element knows the path to the originator of the message. There will be no SIP Proxies in this example, because for Preconditions, Proxies only make more messages that look identical (with the exception of the Via and Max-Forwards headers), and it is not worth the space here to replicate what has been done in SIP RFCs already.
从上面的邀请中，Alice邀请Bob参加一个会议。行的上半部分（行“v=0”上方）是SIP头和头值，下半部分是会话描述协议（SDP）行。SIP头（在第一行之后，称为状态行）不是按任何特定顺序强制执行的，只有一个例外：Via头。它是一个SIP跃点（通过SIP代理）路由路径，该路径具有一个新的Via头行，该头行由该消息穿过的每个SIP元素添加到目标UA。这在功能上类似于RSVP路径消息（构建返回消息发起人的反向路径）。在消息路径的任何一点上，SIP元素都知道消息发起人的路径。在本例中没有SIP代理，因为对于先决条件，代理只会生成更多看起来相同的消息（除了Via和Max Forwards头），因此不值得在这里花费空间来复制SIP RFC中已经完成的工作。
SIP headers that are used for Preconditions are as follows:
用于前置条件的SIP标头如下所示：
o Require header, which contains 3 option tags: "100rel" mandates a reliable provisional response message to the conditions requesting in this INVITE (knowing they are special), "preconditions" mandates that preconditions are attempted, and "resource-priority" mandates support for the Resource-Priority header. Each of these option tags can be explicitly identified in a message failure indication from the called UA to tell the calling UA exactly what was not supported.
o Require header，包含3个选项标记：“100rel”要求对此邀请中请求的条件发出可靠的临时响应消息（知道它们是特殊的），“prepositions”要求尝试预条件，“resource priority”要求支持资源优先级头。这些选项标签中的每一个都可以在来自被调用UA的消息故障指示中明确标识，以准确地告诉调用UA不支持的内容。
Provided that this INVITE message is received as acceptable, this will result in the 183 "Session Progress" message from Bob's UA, a reliable confirmation that preconditions are required for this call.
如果该INVITE消息被接收为可接受的，则将产生来自Bob的UA的183“会话进度”消息，这是对该呼叫需要先决条件的可靠确认。
o Resource-Priority header, which denotes the domain namespace and precedence level of the call on an end-to-end basis.
o Resource Priority header，表示端到端调用的域命名空间和优先级。
This completes SIP's functions in session initiation. Preconditions are requested, required, and signaled for in the SDP portion of the message. SDP is carried in what's called a SIP message body (much like the text in an email message is carried). SDP has special properties (see [RFC2327] for more on SDP, or the MMUSIC WG for ongoing efforts regarding SDP). SDP lines are in a specific order for parsing by end systems. Dialog-generating (or call-generating) SDP message bodies all must have an "m=" line (or media description line). Following the "m=" line are zero or more "a=" lines (or Attribute lines). The "m=" line in Alice's INVITE calls for a voice session (this is where video is identified also) using one of 3 different codecs that Alice supports (0 = G.711, 4 = G.723, and 18 = G.729) that Bob gets to choose from for this session. Bob can choose any of the 3. The first a=rtpmap line is specific to the type of codec these 3 are (PCMU). The next two "a=" lines are the only identifiers that RSVP is to be used for this call. The second "a=" line:
这就完成了会话启动中SIP的功能。先决条件在消息的SDP部分被请求、要求并发出信号。SIP在邮件正文中被称为SDP。SDP具有特殊属性（有关SDP的更多信息，请参见[RFC2327]，有关SDP的持续工作，请参见MMUSIC工作组）。SDP行按特定顺序由终端系统进行解析。对话框生成（或呼叫生成）SDP消息正文都必须有“m=”行（或媒体描述行）。“m=”行后面是零行或多行”a=”行（或属性行）。Alice的INVITE中的“m=”行使用Alice支持的3种不同编解码器（0=G.711、4=G.723和18=G.729）中的一种来调用语音会话（这里也可以识别视频），Bob可以从中为此会话进行选择。Bob可以选择3个选项中的任意一个。第一个a=rtpmap行特定于这三种编解码器的类型（PCMU）。接下来的两行“a=”是RSVP用于此调用的唯一标识符。第二个“a=”行：
a=curr:qos e2e none
a=当前：qos e2e无
identifies the "current" status of qos at Alice's UA. Note: everything in SDP is with respect to the sender of the SDP message body (Alice will never tell Bob how his SDP is; she will only tell Bob about her SDP).
标识Alice UA上qos的“当前”状态。注意：SDP中的所有内容都与SDP消息体的发送者有关（Alice永远不会告诉Bob他的SDP是什么；她只会告诉Bob她的SDP）。
"e2e" means that capacity assurance is required from Alice's UA to Bob's UA; thus, a lack of available capacity assurance in either direction will fail the call attempt.
“e2e”是指从Alice的UA到Bob的UA需要容量保证；因此，在任何方向上缺乏可用容量保证都会使呼叫尝试失败。
"none" means there is no reservation at Alice's UA (to Bob) at this time.
“无”表示目前没有在Alice's UA（对Bob）的预订。
The final "a=" line (a=des) identifies the "desired" level of qos:
最后的“a=”行（a=des）标识了“期望”的qos水平：
a=des:qos mandatory e2e sendrecv
a=des:qos强制e2e sendrecv
"mandatory" means this request for qos MUST be successful, or the call fails.
“强制”表示此qos请求必须成功，否则调用失败。
"e2e" means RSVP is required from Alice's UA to Bob's UA.
“e2e”是指从Alice的UA到Bob的UA需要RSVP。
"sendrecv" means the reservation is in both directions.
“sendrecv”表示预订是双向的。
As discussed, RSVP does not reserve bandwidth in both directions, and it is up to the endpoints to have 2 one-way reservations if that particular application (here, voice) requires it. Voice between Alice and Bob requires 2 one-way reservations. The UAs will be the focal points for both reservations in both directions.
如前所述，RSVP不会在两个方向上保留带宽，如果特定应用程序（此处为语音）需要，则由端点决定是否有两个单向保留。Alice和Bob之间的语音通话需要两个单程预约。UAs将是两个方向上的两个保留的焦点。
Message 2 is the 183 "Session Progress" message sent by Bob to Alice, which indicates to Alice that Bob understands that preconditions are required for this call.
消息2是Bob发送给Alice的183“会话进度”消息，它向Alice表明Bob了解此调用需要先决条件。
[M2 - 183 "Session Progress"]
SIP/2.0 183 Session Progress
Via: SIP/2.0/TCP pc33.usmc.example.mil:5060
;branch=z9hG4bK74bf9 ;received=10.1.3.33
From: Alice <sip:alice@usmc.example.mil>;tag=9fxced76sl
To: Bob <sip:bob@usmc.example.mil>;tag=8321234356
Call-ID: 3848276298220188511@pc33.usmc.example.mil
CSeq: 31862 INVITE
RSeq: 813520
Resource-Priority: dsn.routine
Contact: <sip:bob@usmc.example.mil>
Content-Type: application/sdp
Content-Length: 210
[M2 - 183 "Session Progress"]
SIP/2.0 183 Session Progress
Via: SIP/2.0/TCP pc33.usmc.example.mil:5060
;branch=z9hG4bK74bf9 ;received=10.1.3.33
From: Alice <sip:alice@usmc.example.mil>;tag=9fxced76sl
To: Bob <sip:bob@usmc.example.mil>;tag=8321234356
Call-ID: 3848276298220188511@pc33.usmc.example.mil
CSeq: 31862 INVITE
RSeq: 813520
Resource-Priority: dsn.routine
Contact: <sip:bob@usmc.example.mil>
Content-Type: application/sdp
Content-Length: 210
v=0
o=bob 2890844527 2890844527 IN IP4 usmc.example.mil
c=IN IP4 10.100.50.51
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=curr:qos e2e none
a=des:qos mandatory e2e sendrecv
a=conf:qos e2e recv
v=0
o=bob 2890844527 2890844527 IN IP4 usmc.example.mil
c=IN IP4 10.100.50.51
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=curr:qos e2e none
a=des:qos mandatory e2e sendrecv
a=conf:qos e2e recv
The only interesting header in the SIP portion of this message is the RSeq header, which is the "Reliable Sequence" header. The value is incremented for every Reliable message that's sent in this call setup (to make sure none are lost or to ignore duplicates).
此消息的SIP部分中唯一有趣的头是RSeq头，它是“可靠序列”头。此呼叫设置中发送的每个可靠消息的值都会增加（以确保没有丢失消息或忽略重复消息）。
Bob's SDP indicates several "a=" line statuses and picks a codec for the call. The codec picked is in the m=audio line (the "0" at the end of this line means G.711 will be the codec).
Bob的SDP指示多个“a=”线路状态，并为呼叫选择编解码器。选择的编解码器位于m=音频行中（该行末尾的“0”表示G.711将是编解码器）。
The a=curr line gives Alice Bob's status with regard to RSVP (currently "none").
a=curr行给出了Alice Bob关于RSVP的状态（当前为“无”）。
The a=des line also states the desire for mandatory qos e2e in both directions.
a=des行还说明了在两个方向上对强制qos e2e的需求。
The a=conf line is new. This line means Bob wants confirmation that Alice has 2 one-way reservations before Bob's UA proceeds with the SIP session setup.
a=conf行是新的。这一行表示Bob希望在Bob的UA继续SIP会话设置之前确认Alice有2个单向预约。
This is where "Note-1" applies in Figure 7. At the point that Bob's UA transmits this 183 message, Bob's UA (the one that picked the codec, so it knows the amount of bandwidth to reserve) transmits an RSVP PATH message to Alice's UA. This PATH message will take the route previously discussed in Figure 5:
这是图7中“注1”适用的地方。在Bob的UA传输这条183消息时，Bob的UA（选择编解码器的UA，因此它知道要保留的带宽量）向Alice的UA传输RSVP PATH消息。此PATH消息将采用前面在图5中讨论的路径：
Bob -> R4 -> R3 -> R2 -> R1 -> Alice
Bob -> R4 -> R3 -> R2 -> R1 -> Alice
This is the path of the PATH message, and the reverse will be the path of the reservation setup RESV message, or:
这是path消息的路径，反之为保留设置RESV消息的路径，或者：
Alice -> R1 -> R2 -> R3 -> R4 -> Bob
Alice -> R1 -> R2 -> R3 -> R4 -> Bob
Immediately after Alice transmits the RESV message towards Bob, Alice sends her own PATH message to initiate the other one-way reservation. Bob, receiving that PATH message, will reply with a RESV.
Alice向Bob发送RESV消息后，立即发送她自己的PATH消息以启动另一个单向预订。Bob收到PATH消息后，将使用RESV进行回复。
All this is independent of SIP. However, during this time of reservation establishment, a Provisional Acknowledgement (PRACK) [M3] is sent from Alice to Bob to confirm the request for confirmation of 2 one-way reservations at Alice's UA. This message is acknowledged with a normal 200 OK message [M4]. This is shown in Figure 7.
这一切都是独立的。然而，在预订建立期间，Alice向Bob发送临时确认函（PRACK）[M3]，以确认Alice的UA对2个单向预订的确认请求。此消息通过正常的200 OK消息[M4]确认。如图7所示。
As soon as the RSVP is successfully completed at Alice's UA (knowing that it was the last in the two-way cycle or reservation establishment), at the SIP layer an UPDATE message [M5] is sent to Bob's UA to inform his UA that the current status of RSVP (or qos) is "e2e" and "sendrecv".
一旦在Alice的UA成功完成RSVP（知道这是双向循环或预约建立中的最后一个），在SIP层，将向Bob的UA发送更新消息[M5]，通知他的UA RSVP（或qos）的当前状态为“e2e”和“sendrecv”。
[M5 - UPDATE to Bob that Alice has qos e2e and sendrecv]
UPDATE sip:bob@usmc.example.mil SIP/2.0
Via: SIP/2.0/TCP pc33.usmc.example.mil:5060
;branch=z9hG4bK74bfa
From: Alice <sip:alice@usmc.example.mil>;tag=9fxced76sl
To: Bob <sip:bob@usmc.example.mil>
Call-ID: 3848276298220188511@pc33.usmc.example.mil
Resource-Priority: dsn.routine
Contact: <sip:alice@usmc.example.mil>
CSeq: 10197 UPDATE
Content-Type: application/sdp
Content-Length: 191
[M5 - UPDATE to Bob that Alice has qos e2e and sendrecv]
UPDATE sip:bob@usmc.example.mil SIP/2.0
Via: SIP/2.0/TCP pc33.usmc.example.mil:5060
;branch=z9hG4bK74bfa
From: Alice <sip:alice@usmc.example.mil>;tag=9fxced76sl
To: Bob <sip:bob@usmc.example.mil>
Call-ID: 3848276298220188511@pc33.usmc.example.mil
Resource-Priority: dsn.routine
Contact: <sip:alice@usmc.example.mil>
CSeq: 10197 UPDATE
Content-Type: application/sdp
Content-Length: 191
v=0
o=alice 2890844528 2890844528 IN IP4 usmc.example.mil
c=IN IP4 10.1.3.33
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=curr:qos e2e send
a=des:qos mandatory e2e sendrecv
v=0
o=alice 2890844528 2890844528 IN IP4 usmc.example.mil
c=IN IP4 10.1.3.33
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=curr:qos e2e send
a=des:qos mandatory e2e sendrecv
This is shown by the matching table that can be built from the a=curr line and a=des line. If the two lines match, then no further signaling needs take place with regard to "qos". [M6] is the 200 OK acknowledgement of this synchronization between the two UAs.
这由可从a=curr行和a=des行生成的匹配表显示。如果两条线路匹配，则不需要关于“qos”的进一步信令。[M6]是两个UAs之间此同步的200 OK确认。
[M6 - 200 OK to the UPDATE from Bob indicating synchronization]
SIP/2.0 200 OK sip:bob@usmc.example.mil
Via: SIP/2.0/TCP pc33.usmc.example.mil:5060
;branch=z9hG4bK74bfa
From: Alice <sip:alice@usmc.example.mil>;tag=9fxced76sl
To: Bob <sip:bob@usmc.example.mil>
Call-ID: 3848276298220188511@pc33.usmc.example.mil
Resource-Priority: dsn.routine
Contact: < sip:alice@usmc.example.mil >
CSeq: 10197 UPDATE
Content-Type: application/sdp
Content-Length: 195
[M6 - 200 OK to the UPDATE from Bob indicating synchronization]
SIP/2.0 200 OK sip:bob@usmc.example.mil
Via: SIP/2.0/TCP pc33.usmc.example.mil:5060
;branch=z9hG4bK74bfa
From: Alice <sip:alice@usmc.example.mil>;tag=9fxced76sl
To: Bob <sip:bob@usmc.example.mil>
Call-ID: 3848276298220188511@pc33.usmc.example.mil
Resource-Priority: dsn.routine
Contact: < sip:alice@usmc.example.mil >
CSeq: 10197 UPDATE
Content-Type: application/sdp
Content-Length: 195
v=0
o=alice 2890844529 2890844529 IN IP4 usmc.example.mil
c=IN IP4 10.1.3.33
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=curr:qos e2e sendrecv
a=des:qos mandatory e2e sendrecv
v=0
o=alice 2890844529 2890844529 IN IP4 usmc.example.mil
c=IN IP4 10.1.3.33
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=curr:qos e2e sendrecv
a=des:qos mandatory e2e sendrecv
At this point, the reservation is operational and both UAs know it. Bob's UA now rings, telling Bob the user that Alice is calling him. ([M7] is the SIP indication to Alice that this is taking place). Nothing up until now has involved Bob the user. Bob picks up the phone (generating [M10], from which Alice's UA responds with the final ACK), and RTP is now operating within the reservations between the two UAs.
在这一点上，预订是可操作的，两个UAs都知道这一点。Bob的UA现在打电话给Bob，告诉用户Alice正在给他打电话。（[M7]是向Alice发出的SIP指示，表示正在进行此操作）。到目前为止，用户Bob没有参与任何活动。Bob拿起电话（生成[M10]，Alice的UA通过电话发出最后的应答），RTP现在在两个UAs之间的预定范围内运行。
Now we get to Carol calling Dave. Figure 6 shows a common router interface for the reservation between Alice to Bob, and one that will also be the route for one of the reservations between Carol to Dave. This interface will experience congestion in our example.
现在我们让卡罗尔给戴夫打电话。图6显示了Alice到Bob之间预订的公共路由器接口，以及Carol到Dave之间预订的路由。在我们的示例中，此接口将遇到拥塞。
Carol is now calling Dave at a Resource-Priority level of "Immediate", which is higher in priority than Alice to Bob's "routine". In this continuing example, Router 2's Interface-7 is congested and cannot accept any more RSVP traffic. Perhaps the offered load is at interface capacity. Perhaps Interface-7 is configured with a fixed amount of bandwidth it can allocate for RSVP traffic, and it has reached its maximum without one of the reservations going away through normal termination or forced termination (preemption).
Carol现在以“立即”的资源优先级给Dave打电话，这比Alice给Bob的“例行程序”的优先级要高。在接下来的示例中，路由器2的接口7拥塞，无法接受更多的RSVP流量。可能提供的负载处于接口容量。也许Interface-7配置了它可以为RSVP流量分配的固定带宽，并且它已经达到了它的最大值，没有任何保留通过正常终止或强制终止（抢占）而消失。
Interface-7 is not so full of offered load that it cannot transmit signaling packets, such as Carol's SIP messaging to set up a call to Dave. This should be by design (that not all RSVP traffic can starve an interface from signaling packets). Carol sends her own INVITE with the following important characteristics:
Interface-7的负载并不是很满，它无法传输信令包，比如Carol的SIP消息，以建立对Dave的呼叫。这应该是经过设计的（不是所有的RSVP通信都会使接口缺少信令包）。Carol发送了她自己的邀请，并具有以下重要特征：
[M1 - INVITE from Carol to Dave, RP=Immediate, QOS=e2e and mandatory]
[M1 - INVITE from Carol to Dave, RP=Immediate, QOS=e2e and mandatory]
This packet does *not* affect the reservations between Alice and Bob (SIP and RSVP are at different layers, and all routers are passing signaling packets without problems). Dave sends his M2:
此数据包*不*影响Alice和Bob之间的预约（SIP和RSVP位于不同的层，所有路由器都在毫无问题地传递信令数据包）。Dave发送了他的M2：
[M2 - 183 "Session Progress"]
[M2-183“会议进度”]
with the SDP chart of:
SDP图表包括：
a=curr:qos e2e none
a=当前：qos e2e无
a=des:qos mandatory e2e sendrecv
a=des:qos强制e2e sendrecv
a=conf:qos e2e recv
a=conf:qos e2e recv
indicating he understands RSVP reservations are required e2e for this call to be considered successful. Dave sends his PATH message. The PATH message does *not* affect Alice's reservation; it merely establishes a path for the RESV reservation setup message to take.
表示他理解，若要认为本次通话成功，需要预留RSVP。戴夫发送他的路径信息。路径消息*不*影响Alice的保留；它只是为RESV reservation设置消息建立一条路径。
To keep this example simple, the PATH message from Dave to Carol took this route (which we make different from the route in the reverse direction):
为了简化这个示例，Dave到Carol的路径消息采用了以下路径（我们将其与反向路径不同）：
Dave -> R8 -> R7 -> R6 -> R5 -> Carol
Dave -> R8 -> R7 -> R6 -> R5 -> Carol
causing the reservation to be this route:
使预订成为此路线的原因：
Carol -> R5 -> R6 -> R7 -> R8 -> Dave
Carol -> R5 -> R6 -> R7 -> R8 -> Dave
The Carol-to-Dave reservation above will not traverse any of the same routers as the Alice-to-Bob reservation. When Carol transmits her RESV message towards Dave, she immediately transmits her PATH message to set up the complementary reservation.
上面的Carol-to-Dave保留将不会遍历与Alice-to-Bob保留相同的任何路由器。当Carol向Dave发送RESV消息时，她立即发送PATH消息以建立补充预订。
The PATH message from Carol to Dave be through routers:
从Carol到Dave的路径消息将通过路由器发送：
Carol -> R5 -> R2 -> R3 -> R8 -> Dave
Carol -> R5 -> R2 -> R3 -> R8 -> Dave
Thus, the RESV message will be through routers:
因此，RESV消息将通过路由器发送：
Dave -> R8 -> R3 -> R2 -> R5 -> Carol
Dave -> R8 -> R3 -> R2 -> R5 -> Carol
This RESV message will traverse the same routers, R3 and R2, as the Alice-to-Bob reservation. This RESV message, when received at Interface-7 of R2, will create a congestion situation such that R2 will need to make a decision on whether:
此RESV消息将遍历与Alice to Bob保留相同的路由器R3和R2。当在R2的接口7处收到此RESV消息时，将造成拥塞情况，以便R2需要决定是否：
o to keep the Alice-to-Bob reservation and error the new RESV from Dave, or
o 保留Alice to Bob预订并从Dave处错误发送新RESV，或
o to error the reservation from Alice to Bob in order to make room for the Carol-to-Dave reservation.
o 将Alice对Bob的预订弄错，以便为Carol对Dave的预订腾出空间。
Alice's reservation was set up in SIP at the "routine" precedence level. This will equate to a comparable RSVP priority number (RSVP has 65,535 priority values, or 2*32 bits per [RFC3181]). Dave's RESV equates to a precedence value of "immediate", which is a higher priority. Thus, R2 will preempt the reservation from Alice to Bob and allow the reservation request from Dave to Carol. The proper RSVP error is the ResvErr that indicates preemption. This message travels downstream towards the originator of the RESV message (Bob). This clears the reservation in all routers downstream of R2 (meaning
Alice的预约是在SIP中以“常规”优先级设置的。这将相当于一个可比较的RSVP优先级编号（RSVP有65535个优先级值，或每个[RFC3181]2*32位）。Dave的RESV等同于优先级值“immediate”，这是一个更高的优先级。因此，R2将抢占从Alice到Bob的预订，并允许从Dave到Carol的预订请求。正确的RSVP错误是表示抢占的ResvErr。该消息向下游移动至RESV消息的发起人（Bob）。这将清除R2下游所有路由器中的保留（意味着
R3 and R4). Once Bob receives the ResvErr message indicating preemption has occurred on this reservation, Bob's UA transmits a SIP preemption indication back towards Alice's UA. This accomplishes two things: first, it informs all SIP Servers that were in the session setup path that wanted to remain "dialog stateful" per [RFC3261], and second, it informs Alice's UA that this was a purposeful termination, and to play a preemption tone. The proper indication in SIP of this termination due to preemption is a BYE Method message that includes a Reason Header indicating why this occurred (in this case, "Reserved Resources Preempted"). Here is the message from Bob to Alice that terminates the call in SIP.
R3和R4）。一旦Bob收到指示此预订已发生抢占的ResvErr消息，Bob的UA将SIP抢占指示发送回Alice的UA。这完成了两件事：首先，它通知会话设置路径中的所有SIP服务器，希望按照[RFC3261]保持“对话状态”；其次，它通知Alice的UA这是有意终止，并播放抢占音。SIP中由于抢占而终止的正确指示是一条BYE方法消息，该消息包含一个原因头，指示发生这种情况的原因（在本例中为“保留资源抢占”）。下面是Bob给Alice的消息，它在SIP中终止了呼叫。
BYE sip:alice@usmc.example.mil SIP/2.0
Via: SIP/2.0/TCP swp34.usmc.example.mil
;branch=z9hG4bK776asegma
To: Alice <sip:alice@usmc.example.mil>
From: Bob <sip:bob@usmc.example.mil>;tag=192820774
Reason: preemption ;cause=2 ;text=reserved resourced preempted
Call-ID: 3848276298220188511@pc33.usmc.example.mil
CSeq: 6187 BYE
Contact: <sip:bob@usmc.example.mil>
BYE sip:alice@usmc.example.mil SIP/2.0
Via: SIP/2.0/TCP swp34.usmc.example.mil
;branch=z9hG4bK776asegma
To: Alice <sip:alice@usmc.example.mil>
From: Bob <sip:bob@usmc.example.mil>;tag=192820774
Reason: preemption ;cause=2 ;text=reserved resourced preempted
Call-ID: 3848276298220188511@pc33.usmc.example.mil
CSeq: 6187 BYE
Contact: <sip:bob@usmc.example.mil>
When Alice's UA receives this message, her UA terminates the call, sends a 200 OK to Bob to confirm reception of the BYE message, and plays a preemption tone to Alice the user.
当Alice的UA收到此消息时，她的UA终止呼叫，向Bob发送200 OK以确认收到BYE消息，并向Alice用户播放抢占音。
The RESV message from Dave successfully traverses R2, and Carol's UA receives it. Just as with the Alice-to-Bob call setup, Carol sends an UPDATE message to Dave, confirming she has QoS "e2e" in "sendrecv" directions. Bob acknowledges this with a 200 OK that gives his current status (QoS "e2e" and "sendrecv"), and the call setup in SIP continues to completion.
来自Dave的RESV消息成功地穿越R2，Carol的UA收到了它。就像Alice对Bob的呼叫设置一样，Carol向Dave发送了一条更新消息，确认她在“sendrecv”方向上有QoS“e2e”。Bob通过给出其当前状态（QoS“e2e”和“sendrecv”）的200 OK确认了这一点，SIP中的呼叫设置继续完成。
In summary, Alice set up a call to Bob with RSVP at a priority level of Routine. When Carol called Dave at a high priority, their call would have preempted any lower priority calls if there were a contention for resources. In this case, it occurred and affected the call between Alice and Bob. A router at this congestion point preempted Alice's call to Bob in order to place the higher-priority call between Carol and Dave. Alice and Bob were both informed of the preemption event. Both Alice and Bob's UAs played preemption indications. What was not mentioned in this appendix was that this document RECOMMENDS that router R2 (in this example) generate a syslog message to the domain administrator to properly manage and track such events within this domain. This will ensure that the domain administrators have recorded knowledge of where such events occur, and what the conditions were that caused them.
总之，Alice以例程的优先级设置了对Bob的RSVP调用。当Carol以高优先级呼叫Dave时，如果存在资源争用，他们的呼叫将优先于任何低优先级呼叫。在本例中，它发生并影响了Alice和Bob之间的通话。这个拥塞点的路由器抢占了Alice对Bob的呼叫，以便在Carol和Dave之间进行更高优先级的呼叫。Alice和Bob都被告知了抢占事件。Alice和Bob的UAs都有先占权指示。本附录中未提及的是，本文档建议路由器R2（在本例中）向域管理员生成一条syslog消息，以正确管理和跟踪此域中的此类事件。这将确保域管理员记录此类事件发生的位置以及导致这些事件的条件。
Authors' Addresses
作者地址
Fred Baker Cisco Systems 1121 Via Del Rey Santa Barbara, California 93117 USA
Fred Baker Cisco Systems 1121 Via Del Rey Santa Barbara，加利福尼亚州93117
Phone: +1-408-526-4257
Fax: +1-413-473-2403
EMail: fred@cisco.com
Phone: +1-408-526-4257
Fax: +1-413-473-2403
EMail: fred@cisco.com
James Polk Cisco Systems 2200 East President George Bush Turnpike Richardson, Texas 75082 USA
詹姆斯·波尔克思科系统2200美国德克萨斯州东总统乔治·布什收费公路理查森75082
Phone: +1-817-271-3552
EMail: jmpolk@cisco.com
Phone: +1-817-271-3552
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）提供。