Network Working Group V. Gurbani
Request for Comments: 4904 Bell Laboratories, Alcatel-Lucent
Category: Standards Track C. Jennings
Cisco Systems
June 2007
Network Working Group V. Gurbani
Request for Comments: 4904 Bell Laboratories, Alcatel-Lucent
Category: Standards Track C. Jennings
Cisco Systems
June 2007
Representing Trunk Groups in tel/sip Uniform Resource Identifiers (URIs)
在tel/sip统一资源标识符（URI）中表示中继组
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
This document describes a standardized mechanism to convey trunk group parameters in sip and tel Uniform Resource Identifiers (URIs). An extension to the tel URI is defined for this purpose.
本文档描述了在sip和tel统一资源标识符（URI）中传递中继组参数的标准化机制。为此，定义了teluri的扩展。
Table of Contents
目录
1. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Requirements and Rationale . . . . . . . . . . . . . . . . . . 5
4.1. sip URI or tel URI? . . . . . . . . . . . . . . . . . . . 5
4.2. Trunk Group Namespace: Global or Local? . . . . . . . . . 5
4.3. Originating Trunk Group and Terminating Trunk Group . . . 6
4.4. Intermediary Processing of Trunk Groups . . . . . . . . . 6
5. Trunk Group Identifier: ABNF and Examples . . . . . . . . . . 6
6. Normative Behavior of SIP Entities Using Trunk Groups . . . . 8
6.1. User Agent Client Behavior . . . . . . . . . . . . . . . . 9
6.2. User Agent Server Behavior . . . . . . . . . . . . . . . . 10
6.3. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . 10
7. Example Call Flows . . . . . . . . . . . . . . . . . . . . . . 11
7.1. Reference Architecture . . . . . . . . . . . . . . . . . . 11
7.2. Basic Call Flow . . . . . . . . . . . . . . . . . . . . . 12
7.3. Inter-Domain Call Flow . . . . . . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 16
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
11.1. Normative References . . . . . . . . . . . . . . . . . . . 17
11.2. Informative References . . . . . . . . . . . . . . . . . . 17
1. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Requirements and Rationale . . . . . . . . . . . . . . . . . . 5
4.1. sip URI or tel URI? . . . . . . . . . . . . . . . . . . . 5
4.2. Trunk Group Namespace: Global or Local? . . . . . . . . . 5
4.3. Originating Trunk Group and Terminating Trunk Group . . . 6
4.4. Intermediary Processing of Trunk Groups . . . . . . . . . 6
5. Trunk Group Identifier: ABNF and Examples . . . . . . . . . . 6
6. Normative Behavior of SIP Entities Using Trunk Groups . . . . 8
6.1. User Agent Client Behavior . . . . . . . . . . . . . . . . 9
6.2. User Agent Server Behavior . . . . . . . . . . . . . . . . 10
6.3. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . 10
7. Example Call Flows . . . . . . . . . . . . . . . . . . . . . . 11
7.1. Reference Architecture . . . . . . . . . . . . . . . . . . 11
7.2. Basic Call Flow . . . . . . . . . . . . . . . . . . . . . 12
7.3. Inter-Domain Call Flow . . . . . . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 16
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
11.1. Normative References . . . . . . . . . . . . . . . . . . . 17
11.2. Informative References . . . . . . . . . . . . . . . . . . 17
Call routing in the Public Switched Telephone Network (PSTN) is accomplished by routing calls over specific circuits (commonly referred to as "trunks") between Time Division Multiplexed (TDM) circuit switches. In switches, a group of trunks that connect to the same target switch or network is called a "trunk group". Consequently, trunk groups have labels, which are used as the main indication for the previous and next TDM switch participating in routing the call.
公共交换电话网（PSTN）中的呼叫路由是通过在时分多路复用（TDM）电路交换机之间的特定电路（通常称为“中继”）上路由呼叫来完成的。在交换机中，连接到同一目标交换机或网络的一组中继称为“中继组”。因此，中继组具有标签，这些标签用作参与路由呼叫的上一个和下一个TDM交换机的主要指示。
Formally, we define a trunk and trunk group and related terminology as follows (definition of "trunk" and "trunk group" is from [5]).
在形式上，我们对主干和主干组以及相关术语的定义如下（“主干”和“主干组”的定义来自[5]）。
Trunk: In a network, a communication path connecting two switching systems used in the establishment of an end-to-end connection. In selected applications, it may have both its terminations in the same switching system.
中继线：在网络中，连接两个交换系统的通信路径，用于建立端到端连接。在选定的应用中，它可能在同一个交换系统中有两个终端。
Trunk Group: A set of trunks, traffic engineered as a unit, for the establishment of connections within or between switching systems in which all of the paths are interchangeable. A single trunk group can be shared across multiple switches for redundancy purposes.
中继组：作为一个单元设计的一组中继，用于在交换系统内或交换系统之间建立连接，其中所有路径都是可互换的。出于冗余目的，单个中继组可以跨多个交换机共享。
Digital Signal 0 (DS0): Digital Signal X is a term for a series of standard digital transmission rates based on DS0, a transmission rate of 64 kbps (the bandwidth normally used for one telephone voice channel). The European E-carrier system of transmission also operates using the DS series as a base multiple.
数字信号0（DS0）：数字信号X是基于DS0的一系列标准数字传输速率的术语，传输速率为64 kbps（通常用于一个电话语音信道的带宽）。欧洲E-carrier传输系统也使用DS系列作为基本倍频。
Since the introduction of ubiquitous digital trunking, which resulted in the allocation of DS0s between end offices in minimum groups of 24 (in North America), it has become common to refer to bundles of DS0s as a trunk. Strictly speaking, however, a trunk is a single DS0 between two PSTN end offices; however, for the purposes of this document, the PSTN interface of a gateway acts effectively as an end office (i.e., if the gateway interfaces with Signaling System 7 (SS7), it has its own SS7 point code, and so on). A trunk group, then, is a bundle of DS0s (that need not be numerically contiguous in an SS7 Trunk Circuit Identification Code numbering scheme) that are grouped under a common administrative policy for routing.
自从引入无处不在的数字集群（这导致在终端办公室之间以最少24个组（在北美）分配DS0）以来，将DS0束称为主干变得很常见。然而，严格地说，主干是两个PSTN终端办公室之间的单个DS0；然而，就本文件而言，网关的PSTN接口有效地充当终端办公室（即，如果网关与信令系统7（SS7）接口，则其具有自己的SS7点代码，等等）。因此，中继组是一组DS0（在SS7中继电路标识码编号方案中，这些DS0不需要在数字上连续），这些DS0按照通用的路由管理策略进行分组。
A Session Initiation Protocol (SIP) [3] to PSTN gateway may have trunks that are connected to different carriers. It is entirely reasonable for a SIP proxy to choose -- based on factors not enumerated in this document -- which carrier a call is sent to when it proxies a session setup request to the gateway. Since multiple
PSTN网关的会话发起协议（SIP）[3]可以具有连接到不同载波的中继。SIP代理在向网关代理会话设置请求时，根据本文未列举的因素选择呼叫发送到哪个运营商是完全合理的。自多次
carriers can transport a call to a particular phone number, the phone number itself is not sufficient to identify the carrier at the gateway. An additional piece of information in the form of a trunk group can be used to further pare down the choices at the gateway. As used in this document, trunks are necessarily tied to gateways, and a proxy that uses trunk groups during routing of the request to a particular gateway knows and controls which gateway the call will be routed to, and knows what trunking resources are present on that gateway.
运营商可以将呼叫传送到特定的电话号码，但电话号码本身不足以在网关上识别运营商。可以使用中继组形式的附加信息进一步减少网关上的选择。正如在本文档中使用的，中继必须绑定到网关，并且在将请求路由到特定网关期间使用中继组的代理知道并控制呼叫将路由到哪个网关，并且知道该网关上存在哪些中继资源。
As another example, consider the case where an IP network is being used as a transit network between two PSTN networks. Here, a SIP proxy can apply the originating trunk group to its routing logic to ensure that the same ingress and egress carrier is chosen.
作为另一个例子，考虑IP网络被用作两个PSTN网络之间的传输网络的情况。这里，SIP代理可以将发起中继组应用于其路由逻辑，以确保选择相同的入口和出口载波。
How the proxy picked a particular trunk group is outside the scope of this document ([6] provides one such way); however, once trunk group has been decided upon, this document provides a standardized means to represent it in the signaling messages.
代理选择特定中继组的方式超出了本文档的范围（[6]提供了一种方法）；然而，一旦确定了中继组，本文档提供了在信令消息中表示中继组的标准化方法。
Currently, there isn't any standardized manner of transporting trunk groups between Internet signaling entities. This leads to ambiguity on at least two fronts:
目前，还没有任何标准化的方式在互联网信令实体之间传输中继组。这至少在两个方面导致了歧义：
1. Positional ambiguity: A SIP proxy that wants to send a call to an egress Voice over IP (VoIP) gateway may insert the trunk group as a parameter in the user portion of the Request-URI (R-URI), or it may insert it as a parameter to the R-URI itself. This ambiguity persists in the reverse direction as well, that is, when an ingress VoIP gateway wants to send an incoming call notification to its default outbound proxy.
1. 位置模糊性：希望向出口IP语音（VoIP）网关发送呼叫的SIP代理可以将中继组作为参数插入请求URI（R-URI）的用户部分，也可以将其作为参数插入R-URI本身。这种模糊性也在相反的方向上持续存在，即，当入口VoIP网关想要向其默认出站代理发送传入呼叫通知时。
2. Semantic ambiguity: The lack of any standardized grammar to represent trunk groups leads to the unfortunate choice of ad hoc names and values.
2. 语义歧义：缺乏任何标准化的语法来表示主干组，这导致了对特定名称和值的不幸选择。
VoIP routing entities in the Internet, such as SIP proxies, may be interested in using trunk groups for normal operations. To that extent, any standards-driven requirements will enable proxies from one vendor to interoperate with gateways from yet another vendor. Absent such guidelines, interoperability will suffer, as a proxy vendor must conform to the expectations of a gateway as to where it expects trunk group parameters to be present (and vice versa).
Internet中的VoIP路由实体（如SIP代理）可能对使用中继组进行正常操作感兴趣。在这种程度上，任何标准驱动的需求都将允许一个供应商的代理与另一个供应商的网关进行互操作。如果没有这样的指导原则，互操作性将受到影响，因为代理供应商必须遵守网关关于其预期中继组参数将出现在何处的预期（反之亦然）。
The aim of this specification is to outline how to structure and represent the trunk group parameters as an extension to the tel URI [4] in a standardized manner.
本规范的目的是概述如何以标准化的方式构造和表示中继组参数，作为tel URI[4]的扩展。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[1]中所述进行解释。
This section captures the motivations for the design decisions for the specification of a trunk group. These motivations are captured as a set of requirements that are used to guide the eventual trunk group specification in this document.
本节介绍主干组规范的设计决策动机。这些动机被捕获为一组需求，用于指导本文档中最终的中继组规范。
REQ 1: Trunk group parameters must be defined as an extension to the tel URI [4].
REQ 1：中继组参数必须定义为tel URI的扩展[4]。
The trunk group parameters can be carried in either the sip URI or the tel URI. Since trunk groups are intimately associated with the PSTN, it seems reasonable to define them as extensions to the tel URI (any SIP request that goes to a gateway could reasonably be expected to have a tel URI, in whole or in part, in its R-URI anyway). Furthermore, using the tel URI also allows this format to be reused by non-SIP VoIP protocols (which could include anything from MGCP or Megaco to H.323, if the proper information elements are created).
中继组参数可以在SIPURI或tel URI中携带。由于中继组与PSTN密切相关，因此将它们定义为tel-URI的扩展似乎是合理的（任何到网关的SIP请求都可以合理地预期在其R-URI中全部或部分包含tel-URI）。此外，使用teluri还允许非SIP VoIP协议重用该格式（如果创建了适当的信息元素，可以包括从MGCP或Megaco到H.323的任何内容）。
Finally, once the trunk group is defined for a tel URI, the normative procedures of Section 19.1.6 of [3] can be used to derive an equivalent sip URI from a tel URI, complete with the trunk group parameters.
最后，一旦为tel URI定义了中继组，就可以使用[3]第19.1.6节的标准程序从tel URI推导出等效的sip URI，包括中继组参数。
REQ 2: Inter-domain trunk group name collisions must be prevented.
请求2：必须防止域间中继组名称冲突。
Under normal operations, trunk groups are pertinent only within an administrative domain (i.e., local scope). However, given that inadvertent cross-domain trunk group name collisions may occur, it is desirable to prevent them. The judicious use of namespaces is a solution to this problem. Thus, it seems appropriate to scope the trunk group through a namespace.
在正常操作下，中继组仅与管理域（即本地范围）相关。但是，考虑到可能会发生意外的跨域中继组名称冲突，因此需要防止这些冲突。明智地使用名称空间是这个问题的解决方案。因此，通过名称空间来确定主干组的范围似乎是合适的。
Note: At first glance, it would appear that the use of the tel URI's "phone-context" parameter provides a satisfactory means of imposing a namespace on a trunk group. The "phone-context" parameter identifies the scope of validity of a local telephone number. And therein lies the problem. Semantically, a "phone-context" tel URI parameter is applicable only to a local telephone number and not a global one (i.e., one preceded by a '+'). Trunk groups, on the other hand, may appear in local or global telephone numbers. Thus, what is needed is a new parameter with equivalent functionality of the "phone-context" parameter of the tel URI, but one that is equally applicable to local and global telephone numbers.
注意：乍一看，似乎使用teluri的“phone context”参数提供了一种令人满意的方法，可以将名称空间强加给中继组。“电话上下文”参数标识本地电话号码的有效范围。这就是问题所在。从语义上讲，“phone context”tel URI参数仅适用于本地电话号码，而不适用于全局电话号码（即前面有“+”的号码）。另一方面，中继组可能出现在本地或全球电话号码中。因此，需要的是一个新参数，它的功能与teluri的“phone context”参数相同，但同样适用于本地和全局电话号码。
REQ 3: Originating trunk group and destination trunk group must be able to appear separately and concurrently in a SIP message.
REQ 3：起始中继组和目标中继组必须能够在SIP消息中分别并同时出现。
SIP routing entities can make informed routing decisions based on either the originating or the terminating trunk groups. Thus, it is required that both of these trunk groups be carried in SIP requests.
SIP路由实体可以基于发起或终止中继组做出知情的路由决策。因此，需要在SIP请求中携带这两个中继组。
REQ 4: SIP network intermediaries (proxy servers and redirect servers) should be able to add the destination trunk group attribute to SIP sessions as a route is selected for a call.
REQ 4:SIP网络中介（代理服务器和重定向服务器）应能够在为呼叫选择路由时将目标中继组属性添加到SIP会话。
The Augmented Backus Naur Form [2] syntax for a trunk group identifier is given below and extends the "par" production rule of the tel URI defined in [4]:
主干组标识符的扩展Backus-Naur Form[2]语法如下所示，并扩展了[4]中定义的tel-URI的“par”生成规则：
par = parameter / extension / isdn-subaddress / trunk-group /
trunk-context
par = parameter / extension / isdn-subaddress / trunk-group /
trunk-context
trunk-group = ";tgrp=" trunk-group-label
trunk-context = ";trunk-context=" descriptor
trunk-group = ";tgrp=" trunk-group-label
trunk-context = ";trunk-context=" descriptor
trunk-group-label = 1*( unreserved / escaped /
trunk-group-unreserved )
trunk-group-unreserved = "/" / "&" / "+" / "$"
trunk-group-label = 1*( unreserved / escaped /
trunk-group-unreserved )
trunk-group-unreserved = "/" / "&" / "+" / "$"
descriptor is defined in [4]. unreserved is defined in [3] and [4]. escaped is defined in [3].
描述符在[4]中定义。无保留的定义见[3]和[4]。[3]中定义了转义。
Trunk groups are identified by two parameters: "tgrp" and "trunk-context"; both parameters MUST be present in a tel URI to identify a trunk group. Collectively, these two parameters are called "trunk group parameters" in this specification.
主干组由两个参数标识：“tgrp”和“主干上下文”；这两个参数都必须存在于tel URI中，以标识中继组。在本规范中，这两个参数统称为“中继组参数”。
All implementations conforming to this specification MUST generate both of these parameters when using trunk groups. If an implementation receives a tel URI with only one of the "tgrp" or "trunk-context" parameter, it MUST act as if there were not any trunk group parameters present at all in that URI. Whether or not to further process such an URI is up to the discretion of the implementation; however, if a decision is made to process it, the implementation MUST act as if there were not any trunk group parameters present in the URI.
当使用中继组时，所有符合本规范的实现都必须生成这两个参数。如果一个实现接收到一个只有一个“tgrp”或“trunk context”参数的tel URI，那么它必须像在该URI中根本不存在任何trunk group参数一样工作。是否进一步处理此类URI取决于实现的自由裁量权；但是，如果决定对其进行处理，则实现必须像URI中不存在任何中继组参数一样工作。
The "trunk-context" parameter imposes a namespace on the trunk group by specifying a global number or any number of its leading digits (e.g., +33), or a domain name. Syntactically, it is modeled after the "phone-context" parameter of the tel URI [4], except that unlike the "phone-context" parameter, the "trunk-context" parameter can appear in either a local or global tel URI.
“trunk context”参数通过指定全局数或其任何前导位数（例如，+33）或域名，在trunk组上施加名称空间。在语法上，它是以tel URI的“phone context”参数[4]为模型的，不同于“phone context”参数，“trunk context”参数可以出现在本地或全局tel URI中。
Semantically, the "trunk-context" parameter establishes a scope of the trunk group specified in the "tgrp" parameter, i.e., whether it is valid at a single gateway, a set of gateways, or an entire domain managed by a service provider. The "trunk-context" can contain four discrete value types:
从语义上讲，“trunk context”参数建立了在“tgrp”参数中指定的中继组的范围，即它在单个网关、一组网关或服务提供商管理的整个域中是否有效。“主干上下文”可以包含四种离散值类型：
1. The value in the "trunk-context" literally identifies a host (a gateway), in which case, the trunk groups are scoped to the specific host.
1. “中继上下文”中的值字面上标识主机（网关），在这种情况下，中继组的作用域为特定主机。
2. The value in the "trunk-context" is a subdomain (e.g., "north.example.com"), which identifies a subset of the gateways in a domain across which the trunk groups are shared.
2. “中继上下文”中的值是一个子域（例如，“north.example.com”），它标识域中的网关子集，中继组在该域中共享。
3. The value in the "trunk-context" is a service provider domain (e.g., "example.com"), which identifies all gateways in the specific domain.
3. “中继上下文”中的值是服务提供者域（例如，“example.com”），它标识特定域中的所有网关。
4. The value in the "trunk-context" is a global number or any number of its leading digits; this is useful for provider-wide scoping and does not lend itself very well to specifying trunk groups across a gateway or a set of gateways.
4. “中继上下文”中的值是一个全局数或其任何前导位数；这对于提供程序范围的作用域非常有用，并且不适合在网关或一组网关上指定中继组。
For equivalency purposes, two URIs containing trunk group parameters are equivalent according to the base comparison rules of the URIs. The base comparison rules of a tel URI are specified in Section 4 of [4], and the base comparison rules of a sip URI are specified in Section 19.1.4 of [3].
出于等效目的，根据URI的基本比较规则，包含中继组参数的两个URI是等效的。tel URI的基本比较规则在[4]的第4节中规定，sip URI的基本比较规则在[3]的第19.1.4节中规定。
Examples:
示例：
1. Trunk group in a local number, with a phone-context parameter (line breaks added for readability):
1. 本地号码中的中继组，带有电话上下文参数（为可读性增加了换行符）：
tel:5550100;phone-context=+1-630;tgrp=TG-1;
trunk-context=example.com
tel:5550100;phone-context=+1-630;tgrp=TG-1;
trunk-context=example.com
Transforming this tel URI to a sip URI yields:
sip:5550100;phone-context=+1-630;tgrp=TG-1;
trunk-context=example.com@isp.example.net;user=phone
Transforming this tel URI to a sip URI yields:
sip:5550100;phone-context=+1-630;tgrp=TG-1;
trunk-context=example.com@isp.example.net;user=phone
2. Trunk group in a global number, with a domain name trunk-context:
2. 全局编号中的中继组，具有域名中继上下文：
tel:+16305550100;tgrp=TG-1;trunk-context=example.com
tel:+16305550100;tgrp=TG-1;trunk-context=example.com
Transforming this tel URI to a sip URI yields:
sip:+16305550100;tgrp=TG-1;
trunk-context=example.com@isp.example.net;user=phone
Transforming this tel URI to a sip URI yields:
sip:+16305550100;tgrp=TG-1;
trunk-context=example.com@isp.example.net;user=phone
3. Trunk group in a global number, with a number prefix trunk-context:
3. 全局编号中的中继组，带有数字前缀中继上下文：
tel:+16305550100;tgrp=TG-1;trunk-context=+1-630
tel:+16305550100;tgrp=TG-1;trunk-context=+1-630
Transforming this tel URI to a sip URI yields:
sip:+16305550100;tgrp=TG-1;
trunk-context=+1-630@isp.example.net;user=phone
Transforming this tel URI to a sip URI yields:
sip:+16305550100;tgrp=TG-1;
trunk-context=+1-630@isp.example.net;user=phone
The terminating (or egress) trunk group parameters MUST be specified in the R-URI. This is an indication from a SIP entity to the next downstream entity that a specific terminating (or egress) trunk group should be used.
必须在R-URI中指定终止（或出口）中继组参数。这是从SIP实体到下一个下游实体的指示，表示应使用特定的终端（或出口）中继组。
Note: This is consistent with using the R-URI as a routing element; SIP routing entities may use the trunk group parameter in the R-URI to make intelligent routing decisions. Furthermore, this also satisfies REQ 4, since a SIP network intermediary can modify the R-URI to include the trunk group parameters.
注意：这与使用R-URI作为路由元素是一致的；SIP路由实体可以使用R-URI中的中继组参数来做出智能路由决策。此外，这也满足REQ 4，因为SIP网络中介可以修改R-URI以包括中继组参数。
Conversely, the appearance of the trunk group parameters in the Contact header URI signifies the trunk group over which the call arrived on, i.e., the originating (or ingress) trunk group. Thus, the originating (or ingress) trunk group MUST appear in the Contact header of a SIP request.
相反，联系人报头URI中中继组参数的出现表示呼叫到达的中继组，即发起（或进入）中继组。因此，发起（或进入）中继组必须出现在SIP请求的联系人报头中。
The behavior described in this section effectively addresses REQ 3.
本节中描述的行为有效地解决了REQ 3。
A User Agent Client (UAC) initiating a call that uses trunk groups and supports this specification MUST include the trunk group parameters in the Contact header URI (a Contact URI MUST be a sip or sips URI; thus, what appears in the Contact header is a SIP translation of the tel URI, complete with the trunk group parameters). The trunk group parameters in the Contact header represent the originating trunk group. As a consequence of the processing rules for the Contact header defined in RFC 3261 [3], subsequent requests in the dialog towards this user agent will contain this Contact URI in the R-URI. Note that the user part of this URI, which contains the trunk group parameters, will be copied as a consequence of this processing.
发起使用中继组并支持此规范的呼叫的用户代理客户端（UAC）必须在联系人标头URI中包含中继组参数（联系人URI必须是sip或sips URI；因此，出现在联系人标头中的是tel URI的sip翻译，包括中继组参数）。联系人标头中的中继组参数表示原始中继组。根据RFC 3261[3]中定义的联系人标头处理规则，对话框中针对该用户代理的后续请求将在R-URI中包含该联系人URI。请注意，此URI的用户部分（包含中继组参数）将作为此处理的结果进行复制。
Note: Arguably, the originating trunk group can be part of the From URI. However, semantically, the URI in a From header is an abstract identifier that represents the resource thus identified on a long-term basis. The presence of a trunk group, on the other hand, signifies a binding that is valid for the duration of the session only; a trunk group has no significance once the session is over. Thus, the Contact URI is the best place to impart this information since it has exactly those semantics.
注意：可以说，原始中继组可以是From URI的一部分。然而，从语义上讲，From头中的URI是一个抽象标识符，它表示这样在长期基础上识别的资源。另一方面，主干组的存在表示仅在会话期间有效的绑定；一旦会话结束，中继组就没有意义了。因此，联系人URI是传递此信息的最佳位置，因为它正好具有这些语义。
If the UAC is aware of the routing topology, it MAY insert the destination trunk group parameters in the R-URI of the request. However, in most deployments, the UAC will use the services of a proxy to further route the request, and it will be up to the proxy to insert such parameters in the R-URI (see Section 6.3).
如果UAC知道路由拓扑，它可以在请求的R-URI中插入目标中继组参数。然而，在大多数部署中，UAC将使用代理的服务进一步路由请求，并且将由代理在R-URI中插入此类参数（参见第6.3节）。
To the processing User Agent Server (UAS) associated with a gateway, the trunk group parameters in the R-URI implies that it should use the named trunk group for the outbound call. If a UAS supports trunk groups, but finds that all the trunk circuit identification codes for that particular trunk group are occupied, it MAY send a 603 Decline final response.
对于与网关关联的处理用户代理服务器（UAS），R-URI中的中继组参数意味着它应该为出站调用使用命名的中继组。如果UAS支持中继组，但发现该特定中继组的所有中继电路标识码都已被占用，它可能会发送603拒绝最终响应。
If a UAS supports trunk groups but is not configured with the particular trunk group identified in the R-URI, it SHOULD NOT use any other trunk group other than the one specified in the parameters. In such a case, it MAY reject the request with a 404 final response; or if it makes a decision to process the request in any case, it MUST disregard the values in the "trunk-context" and the "tgrp" parameters.
如果UAS支持中继组，但未配置R-URI中标识的特定中继组，则不应使用参数中指定的中继组以外的任何其他中继组。在这种情况下，它可以用404最终响应拒绝请求；或者，如果它决定在任何情况下处理请求，它必须忽略“trunk context”和“tgrp”参数中的值。
If the receiver of a SIP request is not authoritatively responsible for the value specified in the "trunk-context", it MUST treat the value in the "tgrp" parameter as if it were not there. Whether or not to process the request further is up to the discretion of the processing entity; the request MAY be rejected with a 404 final response. Alternatively, if a decision is made to process the request further, the processing entity MUST disregard the values in the "trunk-context" and the "tgrp" parameters since it is not authoritatively responsible for the value specified in "trunk-context".
如果SIP请求的接收者对“中继上下文”中指定的值没有权威性的责任，那么它必须将“tgrp”参数中的值视为不存在。是否进一步处理请求由处理实体自行决定；请求可能会被404最终响应拒绝。或者，如果决定进一步处理请求，则处理实体必须忽略“中继上下文”中的值和“tgrp”参数，因为它对“中继上下文”中指定的值不负权威性责任。
A proxy server receiving a request that contains the trunk group parameter in the Contact header SHOULD NOT change these parameters as the request traverses through it. Changing these parameters may have adverse consequences, since the UAC that populated the parameters did so on some authoritative knowledge that the proxy may not be privy to. Instead, the proxy SHOULD pass the trunk group parameters in the Contact header unchanged to the client transaction that the proxy creates to send the request downstream.
代理服务器接收到的请求在Contact标头中包含trunk group参数，在请求通过时不应更改这些参数。更改这些参数可能会产生不利后果，因为填充参数的UAC是基于代理可能不知道的某些权威知识而这样做的。相反，代理应将联系人标头中的中继组参数未更改地传递给代理创建的客户端事务，以向下游发送请求。
A proxy that is aware of the routing topology and supports this specification MAY insert destination trunk group parameters in the R-URI if none are present (see Sections 7.1 and 7.2 for an example). However, if destination trunk group parameters are already present in the R-URI, the proxy SHOULD NOT change them unless it has further authoritative information about the routing topology than the upstream client did when it originally inserted the trunk group parameters in the R-URI.
知道路由拓扑并支持此规范的代理可以在不存在目标中继组参数的情况下在R-URI中插入目标中继组参数（示例请参见第7.1和7.2节）。但是，如果目标中继组参数已存在于R-URI中，则代理不应更改这些参数，除非它具有比上游客户端最初在R-URI中插入中继组参数时更权威的路由拓扑信息。
Depending on the specific situation, it is perfectly reasonable for a proxy not to insert the destination trunk group parameters in the R-URI. Consider, for instance, a proxy that understands the originating trunk group parameters and, in accordance with local policy, uses these to route the request to a destination other than a PSTN gateway.
根据具体情况，代理不在R-URI中插入目标中继组参数是完全合理的。例如，考虑了解始发中继线组参数的代理，并根据本地策略使用这些路由将请求路由到PSTN网关以外的目的地。
Consider Figure 1, which depicts a SIP proxy in a routing relationship with three gateways in its domain, GW1, GW2, and GW3. Requests arrive at the SIP proxy through GW1. Gateways GW2 and GW3 are used as egress gateways from the domain. GW2 has two trunk groups configured, TG2-1 and TG2-2. GW3 also has two trunk groups configured, TG3-1 and TG2-2 (TG2-2 is shared between gateways GW2 and GW3).
考虑图1，它描述了SIP代理在其域中的三个网关、GW1、GW2和GW3中的路由关系。请求通过GW1到达SIP代理。网关GW2和GW3用作域的出口网关。GW2配置了两个中继组：TG2-1和TG2-2。GW3还配置了两个中继组，TG3-1和TG2-2（TG2-2在网关GW2和GW3之间共享）。
+-----+ TG2-1
| |--------> To
TG1-1 +-----+ +-------+ +---->| GW2 | TG2-2 PSTN
From ----->| | | SIP | | | |-------->
PSTN | GW1 |--->| Proxy |-----+ +-----+
----->| | +-------+ | +-----+ TG3-1
+-----+ | | |--------> To
+---->| GW3 | TG2-2 PSTN
| |-------->
+-----+
+-----+ TG2-1
| |--------> To
TG1-1 +-----+ +-------+ +---->| GW2 | TG2-2 PSTN
From ----->| | | SIP | | | |-------->
PSTN | GW1 |--->| Proxy |-----+ +-----+
----->| | +-------+ | +-----+ TG3-1
+-----+ | | |--------> To
+---->| GW3 | TG2-2 PSTN
| |-------->
+-----+
Reference Architecture
参考体系结构
GW1 in Figure 1 is always cognizant of any requests that arrive over trunk group TG1-1. If it wishes to propagate the ingress trunk group to the proxy, it must arrange for the trunk group to appear in the Contact header of the SIP request destined to the proxy. The proxy will, in turn, propagate the ingress trunk group in the Contact header further downstream.
图1中的GW1始终知道通过中继组TG1-1到达的任何请求。如果它希望将入口中继组传播到代理，则必须安排中继组出现在发送到代理的SIP请求的联系人标头中。代理将依次在更下游的联系人报头中传播入口中继组。
The proxy uses GW2 and GW3 as egress gateways to the PSTN. It is assumed that the proxy has access to a routing table for GW2 and GW3 that includes the appropriate trunk groups to use when sending a call to the PSTN (exactly how this table is constructed is out of scope for this specification; [6] is one way to do so, a manually created and maintained routing table is another). When the proxy sends a request to either of the egress gateways, and the gateway routing
代理使用GW2和GW3作为PSTN的出口网关。假设代理可以访问GW2和GW3的路由表，其中包括向PSTN发送呼叫时要使用的适当中继组（该表的具体构造方式不在本规范的范围内；[6]是一种方式，手动创建和维护的路由表是另一种方式）。当代理向任一出口网关发送请求时，网关路由
table is so configured that a trunk group is required by the gateway, the proxy must arrange for the trunk group to appear in the SIP R-URI of the request destined to that gateway.
表被配置为网关需要中继组，代理必须安排中继组出现在发送到该网关的请求的SIPR-URI中。
This example uses the reference architecture of Figure 1. Gateways GW1, GW2, and GW3, and the SIP proxy are assumed to be owned by a service provider whose domain is example.com.
此示例使用图1中的参考体系结构。网关GW1、GW2和GW3以及SIP代理假定由域为example.com的服务提供商拥有。
GW1 SIP Proxy GW2
From | | |
PSTN-->| | |
+---F1--------->| |
| +---F2----------->|
... ... ...
| | | Send to PSTN
| | | --> and receive Answer
| | | Complete Message
-----------------------------------------
Call in progress
-----------------------------------------
| | |
| |<-----------F3---+
+<--------------+ |
... ... ...
GW1 SIP Proxy GW2
From | | |
PSTN-->| | |
+---F1--------->| |
| +---F2----------->|
... ... ...
| | | Send to PSTN
| | | --> and receive Answer
| | | Complete Message
-----------------------------------------
Call in progress
-----------------------------------------
| | |
| |<-----------F3---+
+<--------------+ |
... ... ...
Basic Call Flow
基本呼叫流
In the call flow below, certain headers and messages have been omitted for brevity. In F1, GW1 receives a call setup request from the PSTN over a certain trunk group. GW1 arranges for this trunk group to appear in the Contact header of the request destined to the SIP proxy.
在下面的调用流中，为了简洁起见，省略了某些头和消息。在F1中，GW1通过某个中继组接收来自PSTN的呼叫设置请求。GW1安排此中继组出现在发送给SIP代理的请求的联系人标头中。
F1: INVITE sip:+16305550100@example.com;user=phone SIP/2.0 ... Contact: <sip:0100;phone-context=example.com;tgrp=TG1-1; trunk-context=example.com@gw1.example.com;user=phone> ...
F1：邀请sip：+16305550100@example.com;用户=电话SIP/2.0。。。联系人：<sip:0100；电话上下文=example.com；tgrp=TG1-1；trunk context=示例。com@gw1.example.com;用户=电话>。。。
In F2, the SIP proxy translates the R-URI and adds a destination trunk group to the R-URI. The request is then sent to GW2.
在F2中，SIP代理转换R-URI并向R-URI添加目标中继组。然后将请求发送到GW2。
F2:
INVITE sip:+16305550100;tgrp=TG2-1;
trunk-context=example.com@gw2.example.com;user=phone SIP/2.0
...
Record-Route: <sip:proxy.example.com;lr>
Contact: <sip:0100;phone-context=example.com;tgrp=TG1-1;
trunk-context=example.com@gw1.example.com;user=phone>
...
F2:
INVITE sip:+16305550100;tgrp=TG2-1;
trunk-context=example.com@gw2.example.com;user=phone SIP/2.0
...
Record-Route: <sip:proxy.example.com;lr>
Contact: <sip:0100;phone-context=example.com;tgrp=TG1-1;
trunk-context=example.com@gw1.example.com;user=phone>
...
Once the call is established, either end can tear the call down. For illustrative purposes, F3 depicts GW2 tearing the call down. Note that the Contact from F1, including the trunk group parameters, is now the R-URI of the request. When GW1 gets this request, it can associate the call with the appropriate trunk group to deallocate resources.
一旦建立呼叫，任何一端都可以中断呼叫。为了便于说明，F3描述了GW2中断调用。请注意，来自F1的联系人（包括中继组参数）现在是请求的R-URI。当GW1收到此请求时，它可以将调用与适当的中继组关联以释放资源。
F3: BYE sip:0100;phone-context=example.com;tgrp=TG1-1; trunk-context=example.com@gw1.example.com;user=phone SIP/2.0 Route: <sip:proxy.example.com;lr> ...
F3:sip:0100；电话上下文=example.com；tgrp=TG1-1；trunk context=示例。com@gw1.example.com;用户=电话SIP/2.0路由：<SIP:proxy.example.com；lr>。。。
It is worth documenting the behavior when an incoming call from the PSTN is received at a gateway without a calling party number. Consider Figure 1, and assume that GW1 gets a call request from the PSTN without a calling party number. This is not an uncommon case, and may happen for a variety of reasons, including privacy and interworking between different signaling protocols before the request reached GW1. Under normal circumstances (i.e., instances where the calling party number is present in signaling), GW1 would derive a sip URI to insert into the Contact header. This sip URI will contain, as its user portion, the calling party number from the incoming SS7 signaling information. The trunk group parameters then becomes part of the user portion as discussed previously.
当在没有主叫方号码的网关上接收到来自PSTN的传入呼叫时，记录这种行为是值得的。考虑图1，假设GW1从PSTN得到呼叫请求而没有主叫方号码。这种情况并不少见，并且可能由于各种原因而发生，包括在请求到达GW1之前不同信令协议之间的隐私和互通。在正常情况下（即，在信令中存在主叫方号码的情况下），GW1将派生一个SIPURI以插入到联系人报头中。该sip URI将包含来自传入SS7信令信息的呼叫方号码，作为其用户部分。如前所述，中继组参数随后成为用户部分的一部分。
If a gateway receives an incoming call where the calling party number is not available, it MUST create a tel URI containing a token that is generated locally and has local significance to the gateway. Details of generating such a token are implementation dependent; potential candidates include the gateway line number or port number where the call was accepted. This tel URI is subsequently converted to a sip URI to be inserted in the Contact header of the SIP request going downstream from the gateway.
如果网关接收到主叫方号码不可用的传入呼叫，它必须创建一个包含本地生成并对网关具有本地意义的令牌的tel URI。生成这样的令牌的细节取决于实现；潜在的候选者包括接受呼叫的网关线路号或端口号。该tel URI随后被转换为sip URI，以插入网关下游的sip请求的联系人报头中。
Note: The tel scheme does not allow for an empty URI; thus, the global-number or local-number production rule of the tel URI [4] cannot contain an empty string. Consequently, the behavior in the above paragraph is mandated for cases where the incoming SS7 signaling message does not contain a calling party number.
注意：tel方案不允许空URI；因此，tel URI[4]的全局编号或本地编号生成规则不能包含空字符串。因此，对于传入的SS7信令消息不包含呼叫方号码的情况，强制执行上述段落中的行为。
This example demonstrates the advantage of namespaces in trunk groups. In the example flow below, GW1 and SIP Proxy 1 belong to the example.com domain, and SIP Proxy 2 belongs to another domain, example.net. A call arrives at GW1 (F1) and is routed to the example.net domain. In the call flow below, certain headers and messages have been omitted for brevity.
此示例演示了主干组中名称空间的优势。在下面的示例流中，GW1和SIP Proxy 1属于example.com域，而SIP Proxy 2属于另一个域example.net。呼叫到达GW1（F1）并被路由到example.net域。在下面的调用流中，为了简洁起见，省略了某些头和消息。
example.com example.net
/-------------------------\ /-----------\
GW1 SIP Proxy 1 SIP Proxy 2
From | | |
PSTN-->| | |
+---F1--------->| |
| +---F2----------->|
| | |
... ... ...
| +<--F3------------+
... ... ...
example.com example.net
/-------------------------\ /-----------\
GW1 SIP Proxy 1 SIP Proxy 2
From | | |
PSTN-->| | |
+---F1--------->| |
| +---F2----------->|
| | |
... ... ...
| +<--F3------------+
... ... ...
Inter-Domain Call Flow
域间呼叫流
F1: INVITE sip:+16305550100@example.com;user=phone SIP/2.0 ... Contact: <sip:0100;phone-context=example.com;tgrp=TG1-1; trunk-context=example.com@gw1.example.com;user=phone> ...
F1：邀请sip：+16305550100@example.com;用户=电话SIP/2.0。。。联系人：<sip:0100；电话上下文=example.com；tgrp=TG1-1；trunk context=示例。com@gw1.example.com;用户=电话>。。。
In F2, the SIP proxy executes its routing logic and re-targets the R-URI to refer to a resource in example.net domain.
在F2中，SIP代理执行其路由逻辑，并将R-URI重新定位为引用example.net域中的资源。
F2: INVITE sip:+16305550100@example.net;user=phone SIP/2.0 ... Record-Route: <sip:proxy.example.com;lr> Contact: <sip:0100;phone-context=example.com;tgrp=TG1-1; trunk-context=example.com@gw1.example.com;user=phone> ...
F2：邀请sip：+16305550100@example.net;用户=电话SIP/2.0。。。记录路由：<sip:proxy.example.com；lr>联系人：<sip:0100；电话上下文=example.com；tgrp=TG1-1；trunk context=示例。com@gw1.example.com;用户=电话>。。。
In F3, the example.net domain sends a request in the backwards direction. The example.net domain does not interpret the trunk group parameters in the Contact header since they do not belong to that domain. The Contact header, including the trunk group parameters, is simply used as the R-URI in a subsequent request going towards the example.com domain.
在F3中，示例.net域向后发送请求。示例.net域不解释联系人标头中的中继组参数，因为它们不属于该域。联系人头（包括中继组参数）在随后的向example.com域发出的请求中仅用作R-URI。
F3: BYE sip:0100;phone-context=example.com;tgrp=TG1-1; trunk-context=example.com@gw1.example.com;user=phone Route: <sip:proxy.example.com;lr> ...
F3:sip:0100；电话上下文=example.com；tgrp=TG1-1；trunk context=示例。com@gw1.example.com;用户=电话路由：<sip:proxy.example.com；lr>。。。
The trunk group parameters are carried in R-URIs and Contact headers; they are simply a modifier of an address. Any existing trust relationship between the originator of a request and an intermediary (or final recipient) that processes the request is not affected by such a modifier.
中继组参数携带在R-URI和联系人标头中；它们只是地址的修饰语。请求发起人与处理请求的中间人（或最终接收人）之间的任何现有信任关系不受此类修改人的影响。
Maliciously modifying a trunk group of a R-URI in transit may cause the receiving entity (say, a gateway) to prefer one trunk over another, thus leading to attacks that use resources not privy to the call. For example, an attacker who knows the name of a toll-free trunk on a gateway may modify the trunk group in the R-URI to effectively receive free service, or he may modify the trunk group in a R-URI to affect the flow of traffic across trunks. Similarly, modifying the trunk group in a Contact header may cause the routing intermediary to erroneously associate a call with a different source than it would normally be associated with.
恶意修改传输中的R-URI的中继组可能会导致接收实体（例如网关）偏好一个中继而不是另一个中继，从而导致使用与呼叫无关的资源的攻击。例如，知道网关上免费中继的名称的攻击者可以修改R-URI中的中继组以有效地接收免费服务，或者他可以修改R-URI中的中继组以影响跨中继的流量。类似地，修改联系人报头中的中继组可能导致路由中介错误地将呼叫与其通常关联的不同源关联。
Although this specification imparts more information to the R-URI and the Contact header in the form of trunk groups, the class of attacks and possible protection mechanism are the same as that specified for baseline SIP systems [3]. The Security Session Initiation Protocol Secure (SIPS) scheme and the resulting Transport Layer Security (TLS) mechanism SHOULD be used to provide integrity protection, thereby mitigating these attacks.
尽管本规范以中继组的形式向R-URI和联系人报头传递更多信息，但攻击类别和可能的保护机制与为基线SIP系统指定的相同[3]。应使用安全会话启动协议安全（SIPS）方案和由此产生的传输层安全（TLS）机制来提供完整性保护，从而减轻这些攻击。
A question naturally arises: how does the receiver determine whether the sender is authorized to use the resources represented by the trunk group parameters? There are two cases to consider: intra-domain signaling exchange as discussed in Section 7.2, and inter-domain signaling exchange as discussed in Section 7.3.
自然会产生一个问题：接收方如何确定发送方是否有权使用中继组参数表示的资源？有两种情况需要考虑：第7.2节讨论的域内信令交换和第7.3节讨论的域间信令交换。
In the intra-domain case, a proxy receiving trunk group parameters from an upstream user agent (typically a gateway) should only accept them using the SIPS URI scheme; furthermore, it should use HTTP Digest to challenge and properly authorize the sender. A user agent (or a gateway) receiving the trunk group parameters from a proxy will not be able to challenge the proxy using HTTP Digest, but it should examine the X.509 certificate of the proxy to determine whether the proxy is authorized to insert the resources represented by the trunk group parameters into the signaling flow.
在域内情况下，从上游用户代理（通常是网关）接收中继组参数的代理应仅使用SIPS URI方案接受这些参数；此外，它应该使用HTTP摘要来质询并正确授权发送方。从代理接收中继组参数的用户代理（或网关）将无法使用HTTP摘要质询代理，但它应该检查代理的X.509证书，以确定代理是否有权将中继组参数表示的资源插入信令流。
In the inter-domain case, a receiving proxy may depend on the identity stored in the X.509 certificate of the sending proxy to determine whether the sender is authorized to insert the resources represented by the trunk group parameters in the signaling message.
在域间情况下，接收代理可以依赖于存储在发送代理的X.509证书中的标识来确定发送方是否被授权在信令消息中插入由中继组参数表示的资源。
Because of these considerations, the trunk group parameters are only applicable within a set of network nodes among which there is mutual trust. If a node receives a call signaling request from an upstream node that it does not trust, it SHOULD remove the trunk group parameters.
由于这些考虑，中继组参数仅适用于一组相互信任的网络节点。如果一个节点从它不信任的上游节点接收到呼叫信令请求，它应该删除中继组参数。
The privacy information revealed with a trunk group does not generally advertise much information about a particular (human) user. It does, however, convey two pieces of potentially private information that may be considered sensitive by carriers. First, it may reveal how a carrier may be performing least-cost routing and peering; and secondly, it does introduce an additional means for network topology and information of a carrier. It is up to the discretionary judgment of the carrier if it wants to include the trunk group parameters and reveal potentially sensitive information on its network topology. If confidentiality is desired, TLS SHOULD be used to protect this information while in transit.
通过中继组显示的隐私信息通常不会公布关于特定（人类）用户的大量信息。然而，它确实传递了两条可能被运营商视为敏感的私人信息。首先，它可以揭示载波如何执行成本最低的路由和对等；第二，它确实引入了一种额外的方法来获取网络拓扑和运营商信息。如果运营商希望包括中继组参数并披露其网络拓扑上的潜在敏感信息，则由运营商自行决定。如果需要保密，应使用TLS在传输过程中保护这些信息。
This specification does not require any IANA considerations.
本规范不需要考虑任何IANA因素。
The tel URI parameters introduced in this document are registered with IANA through the tel URI parameter registry document [7].
本文档中介绍的tel URI参数通过tel URI参数注册表文档[7]向IANA注册。
The authors would like to acknowledge the efforts of the participants of the SIPPING and IPTEL working group, especially Jeroen van Bemmel, Bryan Byerly, John Hearty, Alan Johnston, Shan Lu, Rohan Mahy, Jon Peterson, Mike Pierce, Adam Roach, Brian Rosen, Jonathan Rosenberg, Dave Oran, Takuya Sawada, Tom Taylor, and Al Varney.
作者要感谢SIPING和IPTEL工作组参与者的努力，特别是Jeroen van Bemmel、Bryan Byerly、John Hearty、Alan Johnston、Shan Lu、Rohan Mahy、Jon Peterson、Mike Pierce、Adam Roach、Brian Rosen、Jonathan Rosenberg、Dave Oran、Takuya Sawada、Tom Taylor和Al Varney。
Jon Peterson was also instrumental in the original formulation of this work.
乔恩·彼得森在这部作品的最初构思中也发挥了重要作用。
Alex Mayrhofer brought up the issue of lexicographic ordering of tel URI parameters when it is converted to a sip or sips URI.
Alex Mayrhofer提出了tel URI参数在转换为sip或sips URI时的字典排序问题。
Ted Hardie, Sam Hartman, and Russ Housley took pains to ensure that the text around URI comparisons and security considerations was as unambiguous as possible.
Ted Hardie、Sam Hartman和Russ Housley努力确保围绕URI比较和安全考虑的文本尽可能明确。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[2] Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 42342005年10月。
[3] 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.
[3] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[4] Schulzrinne, H., "The tel URI for Telephone Calls", RFC 3966, December 2004.
[4] Schulzrinne，H.，“电话呼叫的电话URI”，RFC 3966，2004年12月。
[5] "Telcordia Notes on the Network", Telcordia SR-2275, Issue 04, October 2000, <http://telecom-info.telcordia.com>.
[5] “Telcordia网络笔记”，Telcordia SR-2275，2000年10月第04期<http://telecom-info.telcordia.com>.
[6] Bangalore, M., Kumar, R., Rosenberg, J., Salama, H., and D. Shah, "A Telephony Gateway REgistration Protocol (TGREP)", Work in Progress, January 2007.
[6] 班加罗尔，M.，库马尔，R.，罗森博格，J.，萨拉马，H.，和D.沙阿，“电话网关注册协议（TGREP）”，正在进行的工作，2007年1月。
[7] Jennings, C. and V. Gurbani, "The Internet Assigned Number Authority (IANA) tel Uniform Resource Identifier (URI) Parameter Registry", Work in Progress, December 2006.
[7] Jennings，C.和V.Gurbani，“互联网分配号码管理局（IANA）电话统一资源标识符（URI）参数注册表”，正在进行的工作，2006年12月。
Authors' Addresses
作者地址
Vijay K. Gurbani Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane Rm 9F-546 Lisle, IL 60532 USA
Vijay K.Gurbani Bell实验室，阿尔卡特朗讯2701朗讯巷，美国伊利诺伊州利斯勒9F-546室，邮编：60532
Phone: +1 630 224 0216
EMail: vkg@alcatel-lucent.com
Phone: +1 630 224 0216
EMail: vkg@alcatel-lucent.com
Cullen Jennings Cisco Systems 170 West Tasman Drive Mailstop SJC-21/3 San Jose, CA 95134 USA
美国加利福尼亚州圣何塞市西塔斯曼大道170号邮政站SJC-21/3号库伦詹宁斯思科系统公司，邮编95134
Phone: +1 408 421 9990
EMail: fluffy@cisco.com
Phone: +1 408 421 9990
EMail: fluffy@cisco.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
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, THE IETF TRUST 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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 currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。