Network Working Group D. Willis
Request for Comments: 3608 dynamicsoft Inc.
Category: Standards Track B. Hoeneisen
Switch
October 2003
Network Working Group D. Willis
Request for Comments: 3608 dynamicsoft Inc.
Category: Standards Track B. Hoeneisen
Switch
October 2003
Session Initiation Protocol (SIP) Extension Header Field for Service Route Discovery During Registration
注册期间服务路由发现的会话启动协议（SIP）扩展头字段
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
Abstract
摘要
This document defines a Session Initiation Protocol (SIP) extension header field used in conjunction with responses to REGISTER requests to provide a mechanism by which a registrar may inform a registering user agent (UA) of a service route that the UA may use to request outbound services from the registrar's domain.
本文档定义了一个会话发起协议（SIP）扩展头字段，该字段与注册请求的响应一起使用，以提供一种机制，通过该机制，注册者可以通知注册用户代理（UA）UA可用于从注册者的域请求出站服务的服务路由。
Table of Contents
目录
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Discussion of Mechanism . . . . . . . . . . . . . . . . . . 4
4. Applicability Statement . . . . . . . . . . . . . . . . . . 5
5. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
6. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6.1. Procedures at the UA . . . . . . . . . . . . . . . . . 6
6.2. Procedures at the Proxy . . . . . . . . . . . . . . . 7
6.3. Procedures at the Registrar . . . . . . . . . . . . . 8
6.4. Examples of Usage . . . . . . . . . . . . . . . . . . 9
6.4.1. Example of Mechanism in REGISTER Transaction . 9
6.4.2. Example of Mechanism in INVITE Transaction . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 15
9. Normative References . . . . . . . . . . . . . . . . . . . . 15
10. Informative References . . . . . . . . . . . . . . . . . . . 15
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Discussion of Mechanism . . . . . . . . . . . . . . . . . . 4
4. Applicability Statement . . . . . . . . . . . . . . . . . . 5
5. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
6. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6.1. Procedures at the UA . . . . . . . . . . . . . . . . . 6
6.2. Procedures at the Proxy . . . . . . . . . . . . . . . 7
6.3. Procedures at the Registrar . . . . . . . . . . . . . 8
6.4. Examples of Usage . . . . . . . . . . . . . . . . . . 9
6.4.1. Example of Mechanism in REGISTER Transaction . 9
6.4.2. Example of Mechanism in INVITE Transaction . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 15
9. Normative References . . . . . . . . . . . . . . . . . . . . 15
10. Informative References . . . . . . . . . . . . . . . . . . . 15
11. Intellectual Property Statement. . . . . . . . . . . . . . . 16
12. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 16
13. Full Copyright Statement . . . . . . . . . . . . . . . . . . 17
11. Intellectual Property Statement. . . . . . . . . . . . . . . 16
12. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 16
13. Full Copyright Statement . . . . . . . . . . . . . . . . . . 17
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 BCP 14, RFC 2119 [1].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[1]中的描述进行解释。
The Third Generation Partnership Project (3GPP) established a requirement for discovering home proxies during SIP registration and published this requirement in [6]. The 3GPP network dynamically assigns a home service proxy to each address-of-record (AOR). This assignment may occur in conjunction with a REGISTER operation, or out-of-band as needed to support call services when the address-of-record has no registrations. This home service proxy may provide both inbound (UA terminated) and outbound (UA originated) services.
第三代合作伙伴关系项目（3GPP）规定了在SIP注册期间发现家庭代理的要求，并在[6]中发布了该要求。3GPP网络动态地将家庭服务代理分配给每个记录地址（AOR）。当记录地址没有注册时，此分配可以与注册操作一起进行，也可以根据需要在带外进行，以支持呼叫服务。此家庭服务代理可以提供入站（UA终止）和出站（UA起源）服务。
In the inbound case, the Request-Uniform Resource Identifier (URI) of incoming SIP requests matches the address-of-record of a user associated with the home service proxy. The home service proxy then (in most cases) forwards the request to the registered contact address for that AOR. A mechanism for traversing required proxies between the home service proxy and the registered UA is presented in [4].
在入站情况下，传入SIP请求的请求统一资源标识符（URI）与与与归属服务代理关联的用户的记录地址匹配。然后，家庭服务代理（在大多数情况下）将请求转发到该AOR的注册联系地址。[4]中介绍了在家庭服务代理和注册UA之间遍历所需代理的机制。
Outbound (UA originated) session cases raise another issue. Specifically, "How does the UA know which service proxy to use and how to get there?"
出站（UA发起的）会话案例提出了另一个问题。具体地说，“UA如何知道使用哪个服务代理以及如何到达那里？”
Several mechanisms were proposed in list discussions, including:
在清单讨论中提出了若干机制，包括：
1. Configuration data in the UA. This raises questions of UA configuration management and updating, especially if proxy assignment is very dynamic, such as in load-balancing scenarios.
1. UA中的配置数据。这就提出了UA配置管理和更新的问题，特别是在代理分配非常动态的情况下，例如在负载平衡场景中。
2. Use of some other protocol, such as HTTP, to get configuration data from a configuration server in the home network. While functional, this solution requires additional protocol engines, firewall complexity, operations overhead, and significant additional "over the air" traffic.
2. 使用一些其他协议（如HTTP）从家庭网络中的配置服务器获取配置数据。虽然功能正常，但此解决方案需要额外的协议引擎、防火墙复杂性、操作开销和大量额外的“空中”流量。
3. Use of lookup tables in the home network, as may be done for inbound requests in some 3G networks. This has a relatively high overhead in terms of database operations.
3. 在家庭网络中使用查找表，就像在某些3G网络中对入站请求所做的那样。这在数据库操作方面具有相对较高的开销。
4. Returning a 302 response indicating the service proxy as a new contact, causing the upstream node processing the 302 (ostensibly the UA) to retransmit the request toward the service proxy. While this shares the database operation of the previous alternative, it does explicitly allow for caching the 302 response thereby potentially reducing the frequency and number of database operations.
4. 返回302响应，指示服务代理作为新联系人，使得处理302的上游节点（表面上是UA）向服务代理重新发送请求。虽然这与前面的备选方案共享数据库操作，但它确实明确允许缓存302响应，从而潜在地减少数据库操作的频率和数量。
5. Performing an operation equivalent to record-routing in a REGISTER transaction between the UA and the associated registrar, then storing that route in the UA and reusing it as a service route on future requests originating from the UA. While efficient, this constrains the service route for proxy operations to be congruent with the route taken by the REGISTER message.
5. 在UA和相关注册器之间的注册事务中执行相当于记录路由的操作，然后将该路由存储在UA中，并在将来来自UA的请求中将其作为服务路由重用。虽然效率很高，但这限制了代理操作的服务路由与REGISTER消息采用的路由一致。
6. Returning service route information as the value of a header field in the REGISTER response. While similar to the previous alternative, this approach grants the ability for the registrar to selectively apply knowledge about the topology of the home network in constructing the service route.
6. 将服务路由信息作为寄存器响应中标头字段的值返回。尽管与前面的备选方案类似，该方法允许注册者在构建服务路由时选择性地应用关于家庭网络拓扑的知识。
This document defines this final alternative: returning the service route information as a header field in the REGISTER response. This new header field indicates a "preloaded route" that the UA may wish to use if requesting services from the proxy network associated with the registrar generating the response.
本文档定义了最后一种选择：在寄存器响应中将服务路由信息作为报头字段返回。这个新的报头字段表示如果从与生成响应的注册器相关联的代理网络请求服务，UA可能希望使用的“预加载路由”。
Scenario
脚本
UA1----P1-----| |--R-------|
| | |
P2---| DBMS
| | |
UA2-----------| |--HSP-----|
UA1----P1-----| |--R-------|
| | |
P2---| DBMS
| | |
UA2-----------| |--HSP-----|
In this scenario, we have a "home network" containing routing proxy P2, registrar R, home service proxy HSP, and database DBMS used by both R and HSP. P2 represents the "edge" of the home network from a SIP perspective, and might be called an "edge proxy". UA1 is an external UA behind proxy P1. UA1 discovers P1 via Dynamic Host Configuration Protocol (DHCP) (this is just an example, and other mechanisms besides DHCP are possible). UA2 is another UA on the Internet, and does not use a default outbound proxy. We do not show Domain Name System (DNS) elements in this diagram, but will assume their reasonable availability in the discussion. The mission is for UA1 to discover HSP so that outbound requests from UA1 may be routed (at the discretion of UA1) through HSP, thereby receiving outbound services from HSP.
在这个场景中，我们有一个“家庭网络”，其中包含路由代理P2、注册器R、家庭服务代理HSP，以及由R和HSP使用的数据库DBMS。P2从SIP的角度表示家庭网络的“边缘”，可以称为“边缘代理”。UA1是代理P1后面的外部UA。UA1通过动态主机配置协议（DHCP）发现P1（这只是一个示例，除DHCP之外的其他机制也是可能的）。UA2是Internet上的另一个UA，不使用默认出站代理。在此图中，我们没有显示域名系统（DNS）元素，但将在讨论中假设它们的合理可用性。UA1的任务是发现HSP，以便来自UA1的出站请求可以通过HSP路由（由UA1决定），从而接收来自HSP的出站服务。
UAs may include a Route header field in an initial request to force that request to visit and potentially be serviced by one or more proxies. Using such a route (called a "service route" or "preloaded route") allows a UA to request services from a specific home proxy or network of proxies. The open question is, "How may a UA discover what service route to use?"
UAs可以在初始请求中包括路由头字段，以强制该请求访问，并可能由一个或多个代理提供服务。使用这种路由（称为“服务路由”或“预加载路由”）允许UA从特定的归属代理或代理网络请求服务。开放性问题是，“UA如何发现要使用的服务路线？”
This document defines a header field called "Service-Route" which can contain a route vector that, if used as discussed above, will direct requests through a specific sequence of proxies. A registrar may use a Service-Route header field to inform a UA of a service route that, if used by the UA, will provide services from a proxy or set of proxies associated with that registrar. The Service-Route header field may be included by a registrar in the response to a REGISTER request. Consequently, a registering UA learns of a service route that may be used to request services from the system it just registered with.
本文档定义了一个称为“服务路由”的报头字段，该字段可以包含一个路由向量，如果如上所述使用该向量，将通过特定的代理序列来引导请求。注册器可以使用服务路由报头字段来通知UA服务路由，如果UA使用该服务路由，则该服务路由将从与该注册器相关联的代理或代理集提供服务。服务路由报头字段可由注册器包括在对注册请求的响应中。因此，注册UA了解可用于从其刚刚注册的系统请求服务的服务路由。
The routing established by the Service-Route mechanism applies only to requests originating in the user agent. That is, it applies only to UA originated requests, and not to requests terminated by that UA.
服务路由机制建立的路由仅适用于源自用户代理的请求。也就是说，它仅适用于UA发起的请求，而不适用于由该UA终止的请求。
Simply put, the registrar generates a service route for the registering UA and returns it in the response to each successful REGISTER request. This service route has the form of a Route header field that the registering UA may use to send requests through the service proxy selected by the registrar. The UA would use this route by inserting it as a preloaded Route header field in requests originated by the UA intended for routing through the service proxy.
简单地说，注册器为注册UA生成服务路由，并在对每个成功注册请求的响应中返回该服务路由。该服务路由具有路由头字段的形式，注册UA可使用该字段通过注册器选择的服务代理发送请求。UA将使用此路由，方法是将其作为预加载的路由头字段插入UA发起的请求中，以通过服务代理进行路由。
The mechanism by which the registrar constructs the header field value is specific to the local implementation and outside the scope of this document.
注册器构造头字段值的机制特定于本地实现，不在本文档的范围内。
The Service-Route mechanism is applicable when:
服务路线机制适用于以下情况：
1. The UA registers with a registrar.
1. UA向注册官注册。
2. The registrar has knowledge of a service proxy that should be used by the UA when requesting services from the domain of the registrar. This knowledge may be a result of dynamic assignment or some other mechanism outside the scope of this document.
2. 注册官了解UA在从注册官的域请求服务时应使用的服务代理。这些知识可能是动态分配或本文件范围之外的其他机制的结果。
3. The registrar(s) has/have sufficient knowledge of the network topology, policy, and situation such that a reasonable service route can be constructed.
3. 注册商对网络拓扑、策略和情况有足够的了解，以便能够构建合理的服务路由。
4. The service route constructed by the registrar is the same for all contacts associated with a single address-of-record. This mechanism does not provide for contact-specific service routes.
4. 对于与单个记录地址相关联的所有联系人，注册器构建的服务路由是相同的。此机制不提供特定于联系人的服务路由。
5. Other mechanisms for proposing a service route to the UA are not available or are inappropriate for use within the specific environment.
5. 向UA提议服务路线的其他机制不可用或不适合在特定环境中使用。
Other methods may also be available by which a UA may be informed of a service route. Such alternative methods are outside the scope of this document. Discussion of why one might wish to assign a service route during registration or when it might be appropriate to do so is outside the scope of this document.
还可以使用其他方法来通知UA服务路由。此类替代方法不在本文件范围内。关于为什么在注册期间或何时可能适合分配服务路由的讨论超出了本文档的范围。
The syntax for the Service-Route header field is:
服务路由标头字段的语法为：
Service-Route = "Service-Route" HCOLON sr-value *( COMMA sr-value)
Service Route=“Service Route”HCOLON sr值*（逗号sr值）
sr-value = name-addr *( SEMI rr-param )
sr值=名称地址*（半rr参数）
Note that the Service-Route header field values MUST conform to the syntax of a Route element as defined in [3]. As suggested therein, such values MUST include the loose-routing indicator parameter ";lr" for full compliance with [3].
请注意，服务路由标头字段值必须符合[3]中定义的路由元素的语法。如文中所述，此类值必须包括松散路由指示符参数“lr”，以完全符合[3]。
The allowable usage of header fields is described in Tables 2 and 3 of [3]. The following additions to this table are needed for Service-Route.
[3]的表2和表3中描述了头字段的允许使用情况。维修路线需要在此表中添加以下内容。
Addition of Service-Route to SIP Table 3:
将服务路由添加到SIP表3中：
Header field where proxy ACK BYE CAN INV OPT REG PRA
_______________________________________________________________
Service-Route 2xx ar - - - - - o -
Header field where proxy ACK BYE CAN INV OPT REG PRA
_______________________________________________________________
Service-Route 2xx ar - - - - - o -
The UA performs a registration as usual. The REGISTER response may contain a Service-Route header field. If so, the UA MAY store the value of the Service-Route header field in an association with the address-of-record for which the REGISTER transaction had registered a contact. If the UA supports multiple addresses-of-record, it may be able to store multiple service routes, one per address-of-record. If the UA refreshes the registration, the stored value of the Service-Route is updated according to the Service-Route header field of the latest 200 class response. If there is no Service-Route header field in the response, the UA clears any service route for that address-of-record previously stored by the UA. If the re-registration request is refused or if an existing registration expires and the UA chooses not to re-register, the UA SHOULD discard any stored service route for that address-of-record.
UA像往常一样进行注册。寄存器响应可能包含服务路由头字段。如果是这样，UA可以将服务路由报头字段的值存储在与注册事务已为其注册联系人的记录地址的关联中。如果UA支持多个记录地址，它可能能够存储多个服务路由，每个记录地址一个。如果UA刷新注册，则根据最新200类响应的服务路由报头字段更新服务路由的存储值。如果响应中没有Service Route header字段，UA将清除UA先前存储的记录地址的任何服务路由。如果重新注册请求被拒绝，或者如果现有注册过期，UA选择不重新注册，UA应放弃该记录地址的任何存储服务路由。
The UA MAY choose to exercise a service route for future requests associated with a given address-of-record for which a service route is known. If so, it uses the content of the Service-Route header field as a preloaded Route header field in outgoing initial requests [3]. The UA MUST preserve the order, in case there is more than one Service-Route header field or header field value.
UA可以为与已知服务路由的给定记录地址相关联的未来请求选择使用服务路由。如果是，它将服务路由头字段的内容用作传出初始请求中的预加载路由头字段[3]。如果存在多个服务路由头字段或头字段值，UA必须保留订单。
Loose routes may interact with routing policy in interesting ways. The specifics of how the service route set integrates with any locally required default route and local policy are implementation dependent. For example, some devices will use locally-configured explicit loose routing to reach a next-hop proxy, and others will use a default outbound-proxy routing rule. However, for the result to function, the combination MUST provide valid routing in the local environment. In general, the service route set is appended to any locally configured route needed to egress the access proxy chain. Systems designers must match the service routing policy of their nodes with the basic SIP routing policy in order to get a workable system.
松散路由可能以有趣的方式与路由策略交互。服务路由集如何与任何本地所需的默认路由和本地策略集成的细节取决于实现。例如，一些设备将使用本地配置的显式松散路由到达下一跳代理，而其他设备将使用默认的出站代理路由规则。但是，为了使结果正常工作，组合必须在本地环境中提供有效的路由。通常，服务路由集附加到任何本地配置的路由，这些路由需要退出访问代理链。系统设计者必须将其节点的服务路由策略与基本SIP路由策略相匹配，以获得可行的系统。
The Service-Route header field is generally treated like any other unknown header field by intermediate proxies. They simply forward it on towards the destination. Note that, as usual, intermediate proxies that need to be traversed by future requests within a dialog may record-route. Proxies should not assume that they will be traversed by future requests in a dialog simply because they appear in the Service-Route header field.
中间代理通常将服务路由头字段视为与任何其他未知头字段一样。他们只是简单地将它转发到目的地。请注意，像往常一样，对话框中未来请求需要遍历的中间代理可能会记录路由。代理不应仅仅因为出现在“服务路由头”字段中而认为它们将被对话框中的未来请求遍历。
There is a question of whether proxies processing a REGISTER response may add themselves to the route set in the Service-Route header field. While this would enable dynamic construction of service routes, it has two significant problems. The first is one of transparency, as seen by the registrar: Intermediate proxies could add themselves without the knowledge or consent of the registrar. The second problem is interaction with end-to-end security. If the registrar uses S/MIME techniques to protect the REGISTER response, such additions would be visible to the UA as "man in the middle" alterations in the response. Consequently, intermediate proxies SHOULD NOT alter the value of Service-Route in REGISTER responses, and if they do, the UA MUST NOT be required to accept the alteration.
有一个问题是，处理寄存器响应的代理是否可以将自己添加到服务路由头字段中的路由集。虽然这将实现服务路线的动态构建，但存在两个重大问题。第一个是透明度，正如书记官长所看到的那样：中间代理人可以在书记官长不知情或不同意的情况下添加自己。第二个问题是与端到端安全性的交互。如果注册器使用S/MIME技术来保护注册器响应，则UA可以看到此类添加，即响应中的“中间人”更改。因此，中间代理不应改变寄存器响应中服务路由的值，如果它们改变了，则UA不得被要求接受该改变。
Additional considerations apply if a proxy is "dual homed", meaning connected to two (or more) different networks such that requests are received on one interface and proxied out through another network interface. Proxies implementing multi-homing precisely as documented in [3] record-route a request with the sending interface. When processing the reply, they replace the Record-Route header field value that represents the interface onto which they proxied the request with a new value that represents the interface onto which they will proxy the response. Consequently, the route vector seen at the User Agent Server (UAS) is not the exact inverse of the route vector seen at the User Agent Client (UAC). While in itself harmless, this complicates matters for nodes that use the recorded route vector (or recorded Path vector as per [4]) in the determination of a service route for future use.
如果代理是“双宿”的，则需要考虑其他因素，这意味着连接到两个（或多个）不同的网络，以便在一个接口上接收请求，并通过另一个网络接口进行代理。完全按照[3]中所述实现多归宿的代理使用发送接口记录路由请求。在处理回复时，它们将代表其代理请求的接口的记录路由头字段值替换为代表其将代理响应的接口的新值。因此，在用户代理服务器（UAS）上看到的路由向量与在用户代理客户端（UAC）上看到的路由向量并非完全相反。虽然这本身无害，但对于在确定未来使用的服务路由时使用记录的路由向量（或根据[4]）的记录的路径向量的节点来说，这使问题复杂化。
Instead of following the procedure in [3], proxies used with Service-Route that are inserting Record-Route or Path header field values SHOULD record not one but two route values when processing the request. The first value recorded indicates the receiving interface, and the second indicates the sending interface. When processing the response, no modification of the recorded route is required. This optimization provides for fully invertible routes that can be effectively used in construction of service routes.
在处理请求时，与服务路由一起使用的插入记录路由或路径头字段值的代理不应遵循[3]中的过程，而应记录一个路由值，而应记录两个路由值。记录的第一个值表示接收接口，第二个值表示发送接口。处理响应时，不需要修改记录的路由。这种优化提供了完全可逆的路由，可以有效地用于服务路由的构建。
When a registrar receives a successful REGISTER request, it MAY choose to return one or more Service-Route header field(s) in the 200 class response. The determination(s) of whether to include these header fields(s) into the 200 class response and what value(s) to insert are a matter of local policy and outside the scope of this document.
当注册器接收到成功的注册请求时，它可以选择在200类响应中返回一个或多个服务路由报头字段。是否将这些标题字段包括在200类响应中以及插入什么值的确定是本地政策的问题，不在本文档的范围内。
Having inserted a Service-Route header field or fields, the registrar returns the 200 class response to the UA in accordance with standard procedures.
在插入一个或多个服务路由报头字段后，注册器根据标准程序将200类响应返回给UA。
A REGISTER operation performing a Fetching Bindings (i.e., no Contact header field is present in the request) SHOULD return the same value of Service-Route as returned in the corresponding previous REGISTER response for the address-of-record in question. In some cases, the Service-Route may be dynamically calculated by the registrar rather than stored, and the decision as to whether this route should be recalculated in the event of a Fetching Bindings operation is left to the implementation.
执行抓取绑定的寄存器操作（即，请求中不存在联系人标头字段）应返回与相关记录地址对应的前一个寄存器响应中返回的相同的服务路由值。在某些情况下，服务路由可能由注册器动态计算，而不是存储，并且在执行抓取绑定操作时是否应重新计算该路由的决定留给实现。
Note: A Fetching Bindings operation could be used by the UA to recover a lost value of Service-Route. Alternatively, a UA in this situation could just re-REGISTER.
注意：UA可以使用获取绑定操作来恢复丢失的服务路由值。或者，这种情况下的UA可以重新注册。
Certain network topologies MAY require a specific proxy (e.g., firewall proxy) to be traversed before the home service proxy. Thus, a registrar with specific knowledge of the network topology MAY return more than one Service-Route header field or element in the 200 class response; the order is specified as top-down, meaning the topmost Service-Route entry will be visited first. Such constructions are implementation specific and outside the scope of this document.
某些网络拓扑可能需要在家庭服务代理之前遍历特定代理（例如，防火墙代理）。因此，具有网络拓扑的特定知识的注册器可以在200类响应中返回多个服务路由报头字段或元素；订单被指定为自上而下，这意味着将首先访问最顶端的服务路线入口。此类施工是具体实施的，不在本文件范围内。
In general, the Service-Route header field contains references to elements strictly within the administrative domain of the registrar and home service proxy. For example, consider a case where a user leaves the "home" network and roams into a "visited" network. The registrar cannot be assumed to have knowledge of the topology of the visited network, so the Service-Route it returns contains elements only within the home network.
通常，“服务路由头”字段包含对注册器和家庭服务代理的管理域内的元素的引用。例如，考虑用户离开“家庭”网络并漫游到“被访问”网络的情况。不能假定注册器知道访问网络的拓扑结构，因此它返回的服务路由仅包含家庭网络内的元素。
Note that the inserted Service-Route element(s) MUST conform to the syntax of a Route element as defined in [3]. As suggested therein, such route elements MUST include the loose-routing indicator parameter ";lr" for full compliance with [3].
请注意，插入的服务路由元素必须符合[3]中定义的路由元素语法。如文中所述，此类路线要素必须包括松散路线指示器参数“lr”，以完全符合[3]。
We present an example in the context of the scenario presented in the Background section earlier in this document. The network diagram is replicated below:
我们在本文档前面的背景部分中介绍的场景上下文中提供了一个示例。网络图复制如下：
Scenario
脚本
UA1----P1-----| |--R-------|
| | |
P2---| DBMS
| | |
UA2-----------| |--HSP-----|
UA1----P1-----| |--R-------|
| | |
P2---| DBMS
| | |
UA2-----------| |--HSP-----|
This example shows the message sequence for user agent UA1 registering to HOME.EXAMPLE.COM using registrar R. R returns a Service-Route indicating that UA1 may use home service proxy HSP.HOME.EXAMPLE.COM to receive outbound services from HOME.EXAMPLE.COM.
此示例显示了用户代理UA1使用注册器R注册到HOME.example.COM的消息序列。R返回一条服务路由，指示UA1可以使用HOME服务代理HSP.HOME.example.COM从HOME.example.COM接收出站服务。
Please note that some header fields (e.g., Content-Length) and session descriptions are omitted to provide a shorter and hopefully more readable presentation.
请注意，省略了一些标题字段（例如，内容长度）和会话描述，以提供更短、更具可读性的演示文稿。
Message sequence for REGISTER returning Service-Route:
注册返回服务路由的消息序列：
F1 Register UA1 -> P1
F1寄存器UA1->P1
REGISTER sip:HOME.EXAMPLE.COM SIP/2.0 Via: SIP/2.0/UDP UADDR1.VISITED.EXAMPLE.ORG:5060;branch=z9hG4bKcR1ntRAp To: Lawyer <sip:UA1@HOME.EXAMPLE.COM> From: Lawyer <sip:UA1@HOME.EXAMPLE.COM>;tag=981211 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: <sip:UA1@UADDR1.VISITED.EXAMPLE.ORG> . . .
通过sip/2.0/UDP UADDR1.VISITED.EXAMPLE.ORG:5060注册sip:HOME.EXAMPLE.COM sip/2.0；branch=z9hG4bKcR1ntRAp To:律师<sip:UA1@HOME.EXAMPLE.COM>发件人：律师<sip:UA1@HOME.EXAMPLE.COM>;tag=981211呼叫ID:843817637684230@998sdasdh09CSeq:1826注册联系人：<sip:UA1@UADDR1.VISITED.EXAMPLE.ORG> . . .
F2 Register P1 -> P2
F2寄存器P1->P2
REGISTER sip:HOME.EXAMPLE.COM SIP/2.0 Via: SIP/2.0/UDP P1.VISITED.EXAMPLE.ORG:5060;branch=z9hG4bKlJuB1mcr Via: SIP/2.0/UDP UADDR1.VISITED.EXAMPLE.ORG:5060;branch=z9hG4bKcR1ntRAp To: Lawyer <sip:UA1@HOME.EXAMPLE.COM> From: Lawyer <sip:UA1@HOME.EXAMPLE.COM>;tag=981211 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: <sip:UA1@UADDR1.VISITED.EXAMPLE.ORG> . . .
注册sip:HOME.EXAMPLE.COM sip/2.0 Via:sip/2.0/UDP P1.visted.EXAMPLE.ORG:5060；branch=z9hG4bKlJuB1mcr Via:SIP/2.0/UDP UADDR1.visted.EXAMPLE.ORG:5060；branch=z9hG4bKcR1ntRAp To:律师<sip:UA1@HOME.EXAMPLE.COM>发件人：律师<sip:UA1@HOME.EXAMPLE.COM>;tag=981211呼叫ID:843817637684230@998sdasdh09CSeq:1826注册联系人：<sip:UA1@UADDR1.VISITED.EXAMPLE.ORG> . . .
F3 Register P2 -> R
F3寄存器P2->R
REGISTER sip:HOME.EXAMPLE.COM SIP/2.0 Via: SIP/2.0/UDP P2.HOME.EXAMPLE.COM:5060;branch=z9hG4bKvE0R2l07o2b6T Via: SIP/2.0/UDP P1.VISITED.EXAMPLE.ORG:5060;branch=z9hG4bKlJuB1mcr Via: SIP/2.0/UDP UADDR1.VISITED.EXAMPLE.ORG:5060;branch=z9hG4bKcR1ntRAp To: Lawyer <sip:UA1@HOME.EXAMPLE.COM> From: Lawyer <sip:UA1@HOME.EXAMPLE.COM>;tag=981211 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: <sip:UA1@UADDR1.VISITED.EXAMPLE.ORG> . . .
通过sip/2.0/UDP P2.HOME.EXAMPLE.COM:5060注册sip:HOME.EXAMPLE.COM sip/2.0；branch=z9hG4bKvE0R2l07o2b6T Via:SIP/2.0/UDP P1.visted.EXAMPLE.ORG:5060；branch=z9hG4bKlJuB1mcr Via:SIP/2.0/UDP UADDR1.visted.EXAMPLE.ORG:5060；branch=z9hG4bKcR1ntRAp To:律师<sip:UA1@HOME.EXAMPLE.COM>发件人：律师<sip:UA1@HOME.EXAMPLE.COM>;tag=981211呼叫ID:843817637684230@998sdasdh09CSeq:1826注册联系人：<sip:UA1@UADDR1.VISITED.EXAMPLE.ORG> . . .
F4 R executes Register
F4R执行寄存器
R Stores:
For <sip:UA1@HOME.EXAMPLE.COM>
Contact: <sip:UA1@UADDR1.VISITED.EXAMPLE.ORG>
R Stores:
For <sip:UA1@HOME.EXAMPLE.COM>
Contact: <sip:UA1@UADDR1.VISITED.EXAMPLE.ORG>
F5 R calculates Service Route
F5R计算服务路线
In this example, R is statically configured to reference HSP as a service route, and R also knows that P2 is used as the provider edge proxy, so:
在此示例中，R静态配置为将HSP作为服务路由引用，并且R还知道P2用作提供者边缘代理，因此：
Service-Route: <sip:P2.HOME.EXAMPLE.COM;lr>,
<sip:HSP.HOME.EXAMPLE.COM;lr>
Service-Route: <sip:P2.HOME.EXAMPLE.COM;lr>,
<sip:HSP.HOME.EXAMPLE.COM;lr>
F6 Register Response r -> P2
F6寄存器响应r->P2
SIP/2.0 200 OK Via: SIP/2.0/UDP P2.HOME.EXAMPLE.COM:5060;branch=z9hG4bKvE0R2l07o2b6T Via: SIP/2.0/UDP P1.VISITED.EXAMPLE.ORG:5060;branch=z9hG4bKlJuB1mcr Via: SIP/2.0/UDP UADDR1.VISITED.EXAMPLE.ORG:5060;branch=z9hG4bKcR1ntRAp To: Lawyer <sip:UA1@HOME.EXAMPLE.COM>;tag=87654 From: Lawyer <sip:UA1@HOME.EXAMPLE.COM>;tag=981211 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: <sip:UA1@UADDR1.VISITED.EXAMPLE.ORG> Service-Route: <sip:P2.HOME.EXAMPLE.COM;lr>, <sip:HSP.HOME.EXAMPLE.COM;lr> . . .
SIP/2.0 200 OK Via:SIP/2.0/UDP P2.HOME.EXAMPLE.COM:5060；branch=z9hG4bKvE0R2l07o2b6T Via:SIP/2.0/UDP P1.visted.EXAMPLE.ORG:5060；branch=z9hG4bKlJuB1mcr Via:SIP/2.0/UDP UADDR1.visted.EXAMPLE.ORG:5060；branch=z9hG4bKcR1ntRAp To:律师<sip:UA1@HOME.EXAMPLE.COM>;tag=87654发件人：律师<sip:UA1@HOME.EXAMPLE.COM>;tag=981211呼叫ID:843817637684230@998sdasdh09CSeq:1826注册联系人：<sip:UA1@UADDR1.VISITED.EXAMPLE.ORG>服务路由：<sip:P2.HOME.EXAMPLE.COM；lr>，<sip:HSP.HOME.EXAMPLE.COM；lr>。
F7 Register Response P2 -> P1
F7寄存器响应P2->P1
SIP/2.0 200 OK Via: SIP/2.0/UDP P1.VISITED.EXAMPLE.ORG:5060;branch=z9hG4bKlJuB1mcr Via: SIP/2.0/UDP UADDR1.VISITED.EXAMPLE.ORG:5060;branch=z9hG4bKcR1ntRAp To: Lawyer <sip:UA1@HOME.EXAMPLE.COM>;tag=87654 From: Lawyer <sip:UA1@HOME.EXAMPLE.COM>;tag=981211 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: <sip:UA1@UADDR1.VISITED.EXAMPLE.ORG> Service-Route: <sip:P2.HOME.EXAMPLE.COM;lr>, <sip:HSP.HOME.EXAMPLE.COM;lr> . . .
SIP/2.0 200 OK Via:SIP/2.0/UDP P1.VISITED.EXAMPLE.ORG:5060；branch=z9hG4bKlJuB1mcr Via:SIP/2.0/UDP UADDR1.visted.EXAMPLE.ORG:5060；branch=z9hG4bKcR1ntRAp To:律师<sip:UA1@HOME.EXAMPLE.COM>;tag=87654发件人：律师<sip:UA1@HOME.EXAMPLE.COM>;tag=981211呼叫ID:843817637684230@998sdasdh09CSeq:1826注册联系人：<sip:UA1@UADDR1.VISITED.EXAMPLE.ORG>服务路由：<sip:P2.HOME.EXAMPLE.COM；lr>，<sip:HSP.HOME.EXAMPLE.COM；lr>。
F8 Register Response P1 -> UA1
F8寄存器响应P1->UA1
SIP/2.0 200 OK Via: SIP/2.0/UDP UADDR1.VISITED.EXAMPLE.ORG:5060;branch=z9hG4bKcR1ntRAp To: Lawyer <sip:UA1@HOME.EXAMPLE.COM>;tag=87654 From: Lawyer <sip:UA1@HOME.EXAMPLE.COM>;tag=981211 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: <sip:UA1@UADDR1.VISITED.EXAMPLE.ORG> Service-Route: <sip:P2.HOME.EXAMPLE.COM;lr>, <sip:HSP.HOME.EXAMPLE.COM;lr> . . .
SIP/2.0 200 OK Via:SIP/2.0/UDP UADDR1.VISITED.EXAMPLE.ORG:5060；branch=z9hG4bKcR1ntRAp To:律师<sip:UA1@HOME.EXAMPLE.COM>;tag=87654发件人：律师<sip:UA1@HOME.EXAMPLE.COM>;tag=981211呼叫ID:843817637684230@998sdasdh09CSeq:1826注册联系人：<sip:UA1@UADDR1.VISITED.EXAMPLE.ORG>服务路由：<sip:P2.HOME.EXAMPLE.COM；lr>，<sip:HSP.HOME.EXAMPLE.COM；lr>。
F9 UA1 stores service route for UA1@HOME.EXAMPLE.COM
F9 UA1门店服务路线UA1@HOME.EXAMPLE.COM
This example shows the message sequence for an INVITE transaction originating from UA1 eventually arriving at UA2 using outbound services from HOME.EXAMPLE.COM. UA1 has previously registered with HOME.EXAMPLE.COM and been informed of a service route through HSP.HOME.EXAMPLE.COM. The service being provided by HOME.EXAMPLE.COM is a "logging" service, which provides a record of the call for UA1's use (perhaps the user of UA1 is an attorney who bills for calls to customers).
此示例显示了源自UA1并最终使用HOME.example.COM的出站服务到达UA2的INVITE事务的消息序列。UA1之前已在HOME.EXAMPLE.COM注册，并已通过HSP.HOME.EXAMPLE.COM获知服务路线。HOME.EXAMPLE.COM提供的服务是一种“日志”服务，它提供通话记录供UA1使用（UA1的用户可能是向客户收取电话费的律师）。
Note that in this example UA1 and UA2 are assumed to be registered with the same network (HOME.EXAMPLE.COM). This does not generally need to be the case to use the herein described service route mechanism.
注意，在本例中，假设UA1和UA2在同一网络（HOME.example.COM）中注册。这通常不需要是使用本文描述的服务路由机制的情况。
Message sequence for INVITE using Service-Route:
使用服务路由的INVITE的消息序列：
F1 Invite UA1 -> P1
F1邀请UA1->P1
INVITE sip:UA2@HOME.EXAMPLE.COM SIP/2.0 Via: SIP/2.0/UDP UADDR1.VISITED.EXAMPLE.ORG:5060;branch=z9hG4bKnashds7 To: Customer <sip:UA2@HOME.EXAMPLE.COM> From: Lawyer <sip:UA1@HOME.EXAMPLE.COM>;tag=456248 Call-ID: 38615183343@s1i1l2j6u CSeq: 18 INVITE Contact: <sip:UA1@UADDR1.VISITED.EXAMPLE.ORG> Route: <sip:P2.HOME.EXAMPLE.COM;lr>, <sip:HSP.HOME.EXAMPLE.COM;lr> . . .
邀请sip：UA2@HOME.EXAMPLE.COMSIP/2.0 Via:SIP/2.0/UDP UADDR1.visitored.EXAMPLE.ORG:5060；分支机构=z9hG4bKnashds7至：客户<sip:UA2@HOME.EXAMPLE.COM>发件人：律师<sip:UA1@HOME.EXAMPLE.COM>;tag=456248呼叫ID:38615183343@s1i1l2j6uCSeq:18邀请联系人：<sip:UA1@UADDR1.VISITED.EXAMPLE.ORG>路由：<sip:P2.HOME.EXAMPLE.COM；lr>，<sip:HSP.HOME.EXAMPLE.COM；lr>。
Note: P1 is selected using the "outbound proxy" rule in UA1.
注意：P1是使用UA1中的“出站代理”规则选择的。
F2 Invite P1 -> P2
F2邀请P1->P2
INVITE sip:UA2@HOME.EXAMPLE.COM SIP/2.0 Via: SIP/2.0/UDP P1.VISITED.EXAMPLE.ORG:5060;branch=z9hG4bK34ghi7ab04 Via: SIP/2.0/UDP UADDR1.VISITED.EXAMPLE.ORG:5060;branch=z9hG4bKnashds7 To: Customer <sip:UA2@HOME.EXAMPLE.COM> From: Lawyer <sip:UA1@HOME.EXAMPLE.COM>;tag=456248 Call-ID: 38615183343@s1i1l2j6u CSeq: 18 INVITE Contact: <sip:UA1@UADDR1.VISITED.EXAMPLE.ORG> Record-Route: <sip:P1.VISITED.EXAMPLE.ORG;lr> Route: <sip:P2.HOME.EXAMPLE.COM;lr>, <sip:HSP.HOME.EXAMPLE.COM;lr> . . .
邀请sip：UA2@HOME.EXAMPLE.COMSIP/2.0 Via:SIP/2.0/UDP P1.visted.EXAMPLE.ORG:5060；branch=z9hG4bK34ghi7ab04 Via:SIP/2.0/UDP UADDR1.visted.EXAMPLE.ORG:5060；分支机构=z9hG4bKnashds7至：客户<sip:UA2@HOME.EXAMPLE.COM>发件人：律师<sip:UA1@HOME.EXAMPLE.COM>;tag=456248呼叫ID:38615183343@s1i1l2j6uCSeq:18邀请联系人：<sip:UA1@UADDR1.VISITED.EXAMPLE.ORG>记录路径：<sip:P1.visted.EXAMPLE.ORG；lr>路由：<sip:P2.HOME.EXAMPLE.COM；lr>，<sip:HSP.HOME.EXAMPLE.COM；lr>。
Note: P1 has added itself to the Record Route.
注意：P1已将其自身添加到记录路由。
F3 Invite P2 -> HSP
F3邀请P2->HSP
INVITE sip:UA2@HOME.EXAMPLE.COM SIP/2.0 Via: SIP/2.0/UDP P2.HOME.EXAMPLE.COM:5060;branch=z9hG4bKiokioukju908 Via: SIP/2.0/UDP P1.VISITED.EXAMPLE.ORG:5060;branch=z9hG4bK34ghi7ab04 Via: SIP/2.0/UDP UADDR1.VISITED.EXAMPLE.ORG:5060;branch=z9hG4bKnashds7 To: Customer <sip:UA2@HOME.EXAMPLE.COM> From: Lawyer <sip:UA1@HOME.EXAMPLE.COM>;tag=456248 Call-ID: 38615183343@s1i1l2j6u CSeq: 18 INVITE Contact: <sip:UA1@UADDR1.VISITED.EXAMPLE.ORG> Record-Route: <sip:P2.HOME.EXAMPLE.COM;lr> Record-Route: <sip:P1.VISITED.EXAMPLE.ORG;lr> Route: <sip:HSP.HOME.EXAMPLE.COM;lr> . . .
邀请sip：UA2@HOME.EXAMPLE.COMSIP/2.0 Via:SIP/2.0/UDP P2.HOME.EXAMPLE.COM:5060；branch=Z9HG4BKIIOKIOUKJU908 Via:SIP/2.0/UDP P1.visted.EXAMPLE.ORG:5060；branch=z9hG4bK34ghi7ab04 Via:SIP/2.0/UDP UADDR1.visted.EXAMPLE.ORG:5060；分支机构=z9hG4bKnashds7至：客户<sip:UA2@HOME.EXAMPLE.COM>发件人：律师<sip:UA1@HOME.EXAMPLE.COM>;tag=456248呼叫ID:38615183343@s1i1l2j6uCSeq:18邀请联系人：<sip:UA1@UADDR1.VISITED.EXAMPLE.ORG>记录路由：<sip:P2.HOME.EXAMPLE.COM；lr>记录路由：<sip:P1.visted.EXAMPLE.ORG；lr>路由：<sip:HSP.HOME.EXAMPLE.COM；lr>。
Note: HSP is selected using a DNS lookup for HSP within HOME.EXAMPLE.COM. P2 has added itself to the Record-Route. P2 has removed itself from the Route.
注意：HSP是使用HOME.EXAMPLE.COM中HSP的DNS查找选择的。P2已将自身添加到记录路由。P2已从路由中移除自身。
F4 HSP executes service
F4 HSP执行服务
HSP identifies the service to be executed from UA1's stored profile. The specifics of this are outside the scope of this document. For this example HSP writes a record to "Lawyer's log book", then looks up the AOR "sip:UA2@HOME.EXAMPLE.COM" and discovers that the current contact for UA2 is at host UAADDR2.HOME.EXAMPLE.COM. This will be the Request-URI of the next-hop INVITE.
HSP从UA1存储的配置文件中标识要执行的服务。本文件的具体内容不在本文件范围内。对于本例，HSP将记录写入“律师日志”，然后查找AOR“sip:UA2@HOME.EXAMPLE.COM“并发现UA2的当前联系人位于主机UAADDR2.HOME.EXAMPLE.COM。这将是下一跳邀请的请求URI。
F5 Invite HSP -> P2
F5邀请HSP->P2
INVITE sip:UA2@UAADDR2.HOME.EXAMPLE.COM SIP/2.0
Via: SIP/2.0/USP HSP.HOME.EXAMPLE.COM:5060;branch=z9hG4bKHSP10120323
Via: SIP/2.0/UDP P2.HOME.EXAMPLE.COM:5060;branch=z9hG4bKiokioukju908
Via: SIP/2.0/UDP P1.VISITED.EXAMPLE.ORG:5060;branch=z9hG4bK34ghi7ab04
Via: SIP/2.0/UDP UADDR1.VISITED.EXAMPLE.ORG:5060;branch=z9hG4bKnashds7
To: Customer <sip:UA2@HOME.EXAMPLE.COM>
From: Lawyer <sip:UA1@HOME.EXAMPLE.COM>;tag=456248
Call-ID: 38615183343@s1i1l2j6u
CSeq: 18 INVITE
Contact: <sip:UA1@UADDR1.VISITED.EXAMPLE.ORG>
Record-Route: <sip:HSP.HOME.EXAMPLE.COM;lr>
Record-Route: <sip:P2.HOME.EXAMPLE.COM;lr>
Record-Route: <sip:P1.VISITED.EXAMPLE.ORG;lr>
INVITE sip:UA2@UAADDR2.HOME.EXAMPLE.COM SIP/2.0
Via: SIP/2.0/USP HSP.HOME.EXAMPLE.COM:5060;branch=z9hG4bKHSP10120323
Via: SIP/2.0/UDP P2.HOME.EXAMPLE.COM:5060;branch=z9hG4bKiokioukju908
Via: SIP/2.0/UDP P1.VISITED.EXAMPLE.ORG:5060;branch=z9hG4bK34ghi7ab04
Via: SIP/2.0/UDP UADDR1.VISITED.EXAMPLE.ORG:5060;branch=z9hG4bKnashds7
To: Customer <sip:UA2@HOME.EXAMPLE.COM>
From: Lawyer <sip:UA1@HOME.EXAMPLE.COM>;tag=456248
Call-ID: 38615183343@s1i1l2j6u
CSeq: 18 INVITE
Contact: <sip:UA1@UADDR1.VISITED.EXAMPLE.ORG>
Record-Route: <sip:HSP.HOME.EXAMPLE.COM;lr>
Record-Route: <sip:P2.HOME.EXAMPLE.COM;lr>
Record-Route: <sip:P1.VISITED.EXAMPLE.ORG;lr>
. . .
. . .
Note: P2 selected by outbound proxy rule on HSP. HSP has removed itself from the Route.
注意：P2由HSP上的出站代理规则选择。HSP已从路由中移除。
INVITE propagates toward UA2 as usual.
INVITE像往常一样向UA2传播。
It is possible for proxies between the UA and the registrar during the REGISTER transaction to modify the value of Service-Route returned by the registrar, or to insert a Service-Route even when one was not returned by the registrar. The consequence of such an attack is that future requests made by the UA using the service route might be diverted to or through a node other than would normally be visited. It is also possible for proxies on the INVITE path to execute many different attacks. It is therefore desirable to apply transitive mutual authentication using sips: or other available mechanisms in order to prevent such attacks.
在注册事务期间，UA和注册官之间的代理可以修改注册官返回的服务路径的值，或者即使注册官未返回服务路径，也可以插入服务路径。这种攻击的结果是，UA使用服务路由发出的未来请求可能被转移到或通过正常访问之外的节点。INVITE路径上的代理也可能执行许多不同的攻击。因此，希望使用sips:或其他可用机制应用可传递的相互认证，以防止此类攻击。
The "sips:" URI as defined in [3] defines a mechanism by which a UA may request transport-level message integrity and mutual authentication. Since there is no requirement for proxies to modify messages, S/MIME signed bodies may be used to provide end-to-end protection for the returned value.
[3]中定义的“sips:”URI定义了UA可以请求传输级消息完整性和相互认证的机制。由于不需要代理修改消息，因此可以使用S/MIME签名体为返回值提供端到端保护。
Systems using Service-Route SHOULD provide hop-by-hop message integrity and mutual authentication. UAs SHOULD request this support by using a "sips:" URI. Registrars returning a Service-Route MUST implement end-to-end protection using S/MIME and SHOULD use S/MIME to protect all such responses. UAs receiving Service-Route SHOULD authenticate attached S/MIME bodies if present.
使用服务路由的系统应提供逐跳消息完整性和相互认证。UAs应使用“sips:”URI请求此支持。返回服务路由的注册器必须使用S/MIME实现端到端保护，并应使用S/MIME保护所有此类响应。接收服务路由的UAs应验证连接的S/MIME实体（如果存在）。
This document defines the SIP extension header field "Service-Route" which has been included in the registry of SIP header fields defined in [3]. The change process for SIP, [5] mandates that general SIP extension header fields be defined by a standards-track RFC. This document provides the required definition.
本文档定义了SIP扩展头字段“服务路由”，该字段已包含在[3]中定义的SIP头字段注册表中。SIP的更改过程[5]要求通用SIP扩展头字段由标准跟踪RFC定义。本文件提供了所需的定义。
The following is the registration for the Service-Route header field:
以下是服务路由标头字段的注册：
RFC Number: RFC 3608
RFC编号：RFC 3608
Header Field Name: Service-Route
标题字段名称：服务路由
Compact Form: none
紧凑型：无
[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] Postel, J. and J. Reynolds, "Instructions to RFC Authors", RFC 2223, October 1997.
[2] Postel，J.和J.Reynolds，“RFC作者须知”，RFC 2223，1997年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] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts", RFC 3327, December 2002.
[4] Willis，D.和B.Hoeneisen，“用于注册非相邻联系人的会话启动协议（SIP）扩展头字段”，RFC 3327，2002年12月。
[5] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J. and B. Rosen, "Change Process for the Session Initiation Protocol (SIP)", BCP 67, RFC 3427, December 2002.
[5] Mankin，A.，Bradner，S.，Mahy，R.，Willis，D.，Ott，J.和B.Rosen，“会话启动协议（SIP）的变更过程”，BCP 67，RFC 3427，2002年12月。
[6] Garcia-Martin, M., "3rd-Generation Partnership Project (3GPP) Release 5 requirements on the Session Initiation Protocol (SIP)", Work in Progress, October 2002.
[6] Garcia Martin，M.，“第三代合作伙伴关系项目（3GPP）发布5对会话启动协议（SIP）的要求”，正在进行的工作，2002年10月。
The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何努力来确定任何此类权利。有关IETF在标准跟踪和标准相关文件中权利的程序信息，请参见BCP-11。可从IETF秘书处获得可供发布的权利声明副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涉及实施本标准所需技术的专有权利。请将信息发送给IETF执行董事。
Dean Willis dynamicsoft Inc. 3100 Independence Parkway #311-164 Plano, TX 75075 US
迪安·威利斯动力软件公司，美国德克萨斯州普莱诺市独立大道3100号，邮编：311-164，邮编：75075
Phone: +1 972 473 5455
EMail: dean.willis@softarmor.com
Phone: +1 972 473 5455
EMail: dean.willis@softarmor.com
Bernie Hoeneisen Switch Limmatquai 138 CH-8001 Zuerich Switzerland
Bernie Hoeneisen Switch Limmatquai 138 CH-8001 Zuerich Switch Switch瑞士
Phone: +41 1 268 1515
EMail: hoeneisen@switch.ch, b.hoeneisen@ieee.org
URI: http://www.switch.ch/
Phone: +41 1 268 1515
EMail: hoeneisen@switch.ch, b.hoeneisen@ieee.org
URI: http://www.switch.ch/
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。