Network Working Group                                          D. Willis
Request for Comments: 3327                              dynamicsoft Inc.
Category: Standards Track                                   B. Hoeneisen
                                                                  Switch
                                                           December 2002
        
Network Working Group                                          D. Willis
Request for Comments: 3327                              dynamicsoft Inc.
Category: Standards Track                                   B. Hoeneisen
                                                                  Switch
                                                           December 2002
        

Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts

用于注册非相邻联系人的会话启动协议(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 (2002). All Rights Reserved.

版权所有(C)互联网协会(2002年)。版权所有。

Abstract

摘要

The REGISTER function is used in a Session Initiation Protocol (SIP) system primarily to associate a temporary contact address with an address-of-record. This contact is generally in the form of a Uniform Resource Identifier (URI), such as Contact: <sip:alice@pc33.atlanta.com> and is generally dynamic and associated with the IP address or hostname of the SIP User Agent (UA). The problem is that network topology may have one or more SIP proxies between the UA and the registrar, such that any request traveling from the user's home network to the registered UA must traverse these proxies. The REGISTER method does not give us a mechanism to discover and record this sequence of proxies in the registrar for future use. This document defines an extension header field, "Path" which provides such a mechanism.

在会话启动协议(SIP)系统中,注册功能主要用于将临时联系人地址与记录地址相关联。此联系人通常采用统一资源标识符(URI)的形式,例如联系人:<sip:alice@pc33.atlanta.com>并且通常是动态的,并且与SIP用户代理(UA)的IP地址或主机名相关联。问题在于网络拓扑在UA和注册器之间可能具有一个或多个SIP代理,使得从用户的家庭网络到注册UA的任何请求都必须遍历这些代理。REGISTER方法没有为我们提供一种机制来发现和记录注册器中的代理序列以供将来使用。本文档定义了一个扩展头字段“Path”,它提供了这样一种机制。

Table of Contents

目录

   1.    Background . . . . . . . . . . . . . . . . . . . . . . . . .  2
   2.    Terminology  . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.    Applicability Statement  . . . . . . . . . . . . . . . . . .  3
   4.    Path Header Field Definition and Syntax  . . . . . . . . . .  3
   5.    Usage of Path Header Field . . . . . . . . . . . . . . . . .  5
   5.1   Procedures at the UA . . . . . . . . . . . . . . . . . . . .  5
   5.2   Procedures at Intermediate Proxies . . . . . . . . . . . . .  5
   5.3   Procedures at the Registrar  . . . . . . . . . . . . . . . .  6
   5.4   Procedures at the Home Proxy . . . . . . . . . . . . . . . .  6
   5.5   Examples of Usage  . . . . . . . . . . . . . . . . . . . . .  7
   5.5.1 Example of Mechanism in REGISTER Transaction . . . . . . . .  7
   5.5.2 Example of Mechanism in INVITE Transaction . . . . . . . . . 11
   6.    Security Considerations  . . . . . . . . . . . . . . . . . . 13
   6.1   Considerations in REGISTER Request Processing  . . . . . . . 13
   6.2   Considerations in REGISTER Response Processing . . . . . . . 14
   7.    IANA Considerations  . . . . . . . . . . . . . . . . . . . . 15
   8.    Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
         Normative References . . . . . . . . . . . . . . . . . . . . 16
         Non-Normative References . . . . . . . . . . . . . . . . . . 16
         Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 16
         Full Copyright Statement . . . . . . . . . . . . . . . . . . 17
        
   1.    Background . . . . . . . . . . . . . . . . . . . . . . . . .  2
   2.    Terminology  . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.    Applicability Statement  . . . . . . . . . . . . . . . . . .  3
   4.    Path Header Field Definition and Syntax  . . . . . . . . . .  3
   5.    Usage of Path Header Field . . . . . . . . . . . . . . . . .  5
   5.1   Procedures at the UA . . . . . . . . . . . . . . . . . . . .  5
   5.2   Procedures at Intermediate Proxies . . . . . . . . . . . . .  5
   5.3   Procedures at the Registrar  . . . . . . . . . . . . . . . .  6
   5.4   Procedures at the Home Proxy . . . . . . . . . . . . . . . .  6
   5.5   Examples of Usage  . . . . . . . . . . . . . . . . . . . . .  7
   5.5.1 Example of Mechanism in REGISTER Transaction . . . . . . . .  7
   5.5.2 Example of Mechanism in INVITE Transaction . . . . . . . . . 11
   6.    Security Considerations  . . . . . . . . . . . . . . . . . . 13
   6.1   Considerations in REGISTER Request Processing  . . . . . . . 13
   6.2   Considerations in REGISTER Response Processing . . . . . . . 14
   7.    IANA Considerations  . . . . . . . . . . . . . . . . . . . . 15
   8.    Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
         Normative References . . . . . . . . . . . . . . . . . . . . 16
         Non-Normative References . . . . . . . . . . . . . . . . . . 16
         Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 16
         Full Copyright Statement . . . . . . . . . . . . . . . . . . 17
        
1. Background
1. 出身背景

3GPP established a requirement for discovering intermediate proxies during SIP registration and published this requirement in [5].

3GPP制定了在SIP注册期间发现中间代理的要求,并在[5]中发布了该要求。

Scenario:

脚本:

   UA1----P1-----P2-----P3------REGISTRAR
        
   UA1----P1-----P2-----P3------REGISTRAR
        

UA1 wishes to register with REGISTRAR. However, due to network topology, UA1 must use P1 as an "outbound proxy", and all requests between UA1 and REGISTRAR must also traverse P1, P2, and P3 before reaching REGISTRAR. Likewise, all requests between REGISTRAR and UA1 must also traverse P3, P2, and P1 before reaching UA1.

UA1希望在注册处注册。然而,由于网络拓扑的原因,UA1必须使用P1作为“出站代理”,并且UA1和注册器之间的所有请求在到达注册器之前也必须遍历P1、P2和P3。同样,在到达UA1之前,注册器和UA1之间的所有请求也必须遍历P3、P2和P1。

UA1 has a standing relationship with REGISTRAR. How UA1 establishes this relationship is outside the scope of this document. UA1 discovers P1 as a result of configuration, DHCP assignment or other similar operation, also outside the scope of this document. REGISTRAR has a similar "default outbound proxy" relationship with P3.

UA1与注册机构有长期合作关系。UA1如何建立这种关系超出了本文件的范围。UA1通过配置、DHCP分配或其他类似操作发现P1,也不在本文档范围内。注册商与P3有类似的“默认出站代理”关系。

Eventually, REGISTRAR or a "home proxy" (a proxy serving as the terminal point for routing an address-of-record) closely related to it will receive a request destined for UA1. It needs to know which proxies must be transited by that request in order to get back to UA1. In some cases, this information may be deducible from SIP routing configuration tables or from DNS entries. In other cases, such as that raised by 3GPP, the information is not readily available outside of the SIP REGISTER transaction.

最终,与之密切相关的注册器或“归属代理”(作为路由记录地址的终点的代理)将接收到一个目的地为UA1的请求。它需要知道该请求必须传输哪些代理才能返回UA1。在某些情况下,可以从SIP路由配置表或DNS条目中推断此信息。在其他情况下,例如3GPP提出的情况,除了SIP寄存器事务之外,该信息不容易获得。

The Path extension header field allows accumulating and transmitting the list of proxies between UA1 and REGISTRAR. Intermediate nodes such as P1 may statefully retain Path information if needed by operational policy. This mechanism is in many ways similar to the operation of Record-Route in dialog-initiating requests. The routing established by the Path header field mechanism applies only to requests transiting or originating in the home domain.

路径扩展头字段允许在UA1和注册器之间累积和传输代理列表。如果操作策略需要,诸如P1的中间节点可以有状态地保留路径信息。该机制在许多方面类似于发起请求的对话框中记录路由的操作。路径头字段机制建立的路由仅适用于在主域中传输或发起的请求。

2. Terminology
2. 术语

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 [3].

本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[3]中的说明进行解释。

3. Applicability Statement
3. 适用性声明

The Path mechanism is applicable whenever there are intermediate proxies between a SIP UA and a SIP Registrar used by that UA where the following conditions are true:

只要SIP UA和该UA使用的SIP注册器之间存在中间代理,且满足以下条件,则路径机制适用:

1. One or more of the intermediate proxies are visited by registration requests from the UA to the Registrar. 2. The same intermediate proxies or a set of proxies known to the intermediate proxies must be traversed, in reverse order, by requests sent through a home proxy to the UA. In the simplest form, the route between the home proxy and the UA is the exact inverse of the route between the UA and the route between the UA and the registrar. 3. The network topology is such that the intermediate proxies which must be visited are NOT implied by SIP routing tables, DNS, or similar mechanisms.

1. UA向注册官发出的注册请求访问一个或多个中间代理。2.相同的中间代理或中间代理已知的一组代理必须通过通过主代理发送到UA的请求以相反顺序遍历。在最简单的形式中,归属代理和UA之间的路由与UA之间的路由以及UA和注册器之间的路由完全相反。3.网络拓扑使得必须访问的中间代理不会被SIP路由表、DNS或类似机制暗示。

4. Path Header Field Definition and Syntax
4. 路径头字段定义和语法

The Path header field is a SIP extension header field with syntax very similar to the Record-Route header field. It is used in conjunction with SIP REGISTER requests and with 200 class messages in response to REGISTER (REGISTER responses).

路径头字段是一个SIP扩展头字段,其语法与记录路由头字段非常相似。它与SIP注册请求和200个类消息一起用于响应注册(注册响应)。

A Path header field MAY be inserted into a REGISTER by any SIP node traversed by that request. Like the Route header field, sequential Path header fields are evaluated in the sequence in which they are present in the request, and Path header fields MAY be combined into compound Path header in a single Path header field. The registrar reflects the accumulated Path back into the REGISTER response, and intermediate nodes propagate this back toward the originating UA. The originating UA is therefore informed of the inclusion of nodes on its registered Path, and MAY use that information in other capacities outside the scope of this document.

路径头字段可以由该请求所遍历的任何SIP节点插入到寄存器中。与路由头字段类似,顺序路径头字段按照它们在请求中出现的顺序进行评估,并且路径头字段可以组合成单个路径头字段中的复合路径头。注册器将累积路径反射回寄存器响应中,中间节点将该路径传播回发起UA。因此,始发UA被告知其注册路径上包含节点,并且可以在本文件范围之外的其他容量中使用该信息。

The difference between Path and Record-Route is that Path applies to REGISTER and 200 class responses to REGISTER. Record-Route doesn't, and can't be defined in REGISTER for reasons of backward compatibility. Furthermore, the vector established by Record-Route applies only to requests within the dialog that established that Record-Route, whereas the vector established by Path applies to future dialogs.

路径和记录路由的区别在于路径应用于寄存器,200个类响应应用于寄存器。记录路由不存在,并且由于向后兼容的原因,无法在寄存器中定义。此外,由记录路由建立的向量仅适用于建立该记录路由的对话框内的请求,而由路径建立的向量适用于未来的对话框。

The syntax for Path is defined as follows:

Path的语法定义如下:

Path = "Path" HCOLON path-value *( COMMA path-value )

Path=“Path”HCOLON路径值*(逗号路径值)

path-value = name-addr *( SEMI rr-param )

路径值=名称地址*(半rr参数)

Note that the Path header field values conform to the syntax of a Route element as defined in [1]. As suggested therein, such values MUST include the loose-routing indicator parameter ";lr" for full compliance with [1].

请注意,路径头字段值符合[1]中定义的路由元素的语法。如文中所述,此类值必须包括松散路由指示符参数“lr”,以完全符合[1]。

The allowable usage of header fields is described in Tables 2 and 3 of SIP [1]. The following additions to this table are needed for Path.

SIP[1]的表2和表3中描述了头字段的允许使用情况。Path需要在此表中添加以下内容。

Support for the Path header field MAY be indicated by a UA by including the option-tag "path" in a Supported header field.

UA可通过在支持的报头字段中包含选项标记“Path”来指示对路径报头字段的支持。

Addition of Path to SIP Table 3:

将路径添加到SIP表3:

      Header field          where   proxy ACK BYE CAN INV OPT REG
      ___________________________________________________________
      Path                    R       ar   -   -   -   -   -   o
      Path                   2xx       -   -   -   -   -   -   o
        
      Header field          where   proxy ACK BYE CAN INV OPT REG
      ___________________________________________________________
      Path                    R       ar   -   -   -   -   -   o
      Path                   2xx       -   -   -   -   -   -   o
        
5. Usage of Path Header Field
5. 路径头字段的用法
5.1 Procedures at the UA
5.1 行动单位的程序

The UA executes its register operation as usual. The response MAY contain a Path header field. The general operation of the UA is to ignore the Path header field in the response. It MAY choose to display the contents of the Path header field to the user or take other action outside the scope of this document. The Path information in the REGISTER response lets the UA know what intermediate proxies were added during registration. Examination of this information may be important from a security perspective, as such inspection might allow the UA to detect intermediate proxies that have inappropriately added themselves.

UA像往常一样执行其寄存器操作。响应可能包含路径头字段。UA的一般操作是忽略响应中的路径头字段。它可以选择向用户显示路径头字段的内容,或者执行本文档范围之外的其他操作。寄存器响应中的路径信息让UA知道在注册期间添加了哪些中间代理。从安全角度来看,检查此信息可能很重要,因为此类检查可能允许UA检测不适当添加自身的中间代理。

The UA SHOULD include the option tag "path" as a header field value in all Supported header fields, and SHOULD include a Supported header field in all requests.

UA应在所有受支持的标头字段中包含选项标记“path”作为标头字段值,并在所有请求中包含受支持的标头字段。

The UA MAY include a Path header field in a request. This is not broadly applicable and caution must be taken to insure proper function, as the Path header field inserted by the UA may have additional Path header field values appended by intermediate proxies. Such proxies are not aware that the Path header field value was inserted by a UA, and will treat it as if it had been inserted by a previously traversed proxy, which could result in unexpected routing behavior wherein the UA is asked to act as a proxy.

UA可以在请求中包括路径报头字段。这并不广泛适用,必须注意确保正确的功能,因为UA插入的路径头字段可能有附加的路径头字段值,并由中间代理附加。此类代理不知道路径头字段值是由UA插入的,并将其视为是由先前遍历的代理插入的,这可能导致意外的路由行为,其中UA被要求充当代理。

5.2 Procedures at Intermediate Proxies
5.2 中间代理的程序

When a proxy processing a REGISTER request wishes to be on the path for future requests toward the UA originating that REGISTER request, the proxy inserts a URI for that proxy as the topmost value in the Path header field (or inserts a new topmost Path header) before proxying that request. It is also possible for a proxy with specific knowledge of network topology to add a Path header field value referencing another node, thereby allowing construction of a Path which is discongruent with the route taken by the REGISTER request. Such a construction is implementation specific and outside the scope of this document.

当处理注册请求的代理希望位于将来向发起该注册请求的UA发出请求的路径上时,代理在代理该请求之前,将该代理的URI作为最顶端的值插入路径头字段(或插入新的最顶端的路径头)。具有特定网络拓扑知识的代理还可以添加引用另一节点的路径头字段值,从而允许构建与注册请求所采用的路由不一致的路径。此类施工是具体实施的,不在本文件范围内。

Intermediate proxies SHOULD NOT add a Path header field to a request unless the UA has indicated support for this extension with a Supported header field value. If the UA has indicated support and the proxy requires the registrar to support the Path extension, then the proxy SHOULD insert a Requires header field value for this extension. If the UA has not indicated support for the extension and the proxy requires support for it in the registrar, the proxy SHOULD

中间代理不应向请求添加路径头字段,除非UA已使用支持的头字段值表示支持此扩展。如果UA已表示支持,且代理要求注册器支持路径扩展,则代理应为此扩展插入requires标头字段值。如果UA未表示支持延期,且代理人要求注册官对延期给予支持,则代理人应

reject the request with a 421 response indicating a requirement for the extension.

以421响应拒绝请求,该响应指示扩展的要求。

Proxies processing a REGISTER response SHOULD NOT alter any Path header field values that may be present in the response. The registrar MAY protect the Path header field in the response by including it in a protected S/MIME body, and alterations of the Path by an intermediate proxy can therefore be detected by the UA as man-in-the-middle attacks. Proxies SHOULD only consider altering the value of a Path header field in the REGISTER response if they have the credentials to correctly alter the S/MIME body to account for the change.

处理寄存器响应的代理不应改变响应中可能存在的任何路径头字段值。注册器可以通过将路径报头字段包括在受保护的S/MIME主体中来保护响应中的路径报头字段,因此,UA可以将中间代理对路径的更改检测为中间人攻击。代理应该只考虑更改登记响应中路径标题字段的值,如果它们有凭证来正确地更改S/MIME主体以解释更改。

5.3 Procedures at the Registrar
5.3 书记官长的程序

If a Path header field exists in a successful REGISTER request, the registrar constructs an ordered list of route elements (a path vector) from the nodes listed in the Path header field values, preserving the order as indicated in the Path header field values. The registrar then stores this path vector in association with that contact and the address-of-record indicated in the REGISTER request (the "binding" as defined in [1]). The registrar copies the Path header field values into a Path header field in the successful (200 class) REGISTER response. In the event that the home proxy and registrar are not co-located, the registrar MAY apply a locally-determined transformation to the stored path vector.

如果成功的注册请求中存在路径头字段,则注册器从路径头字段值中列出的节点构造路由元素的有序列表(路径向量),保留路径头字段值中指示的顺序。然后,注册员将该路径向量与该联系人和注册请求中指示的记录地址(如[1]中定义的“绑定”)相关联地存储。注册器将路径头字段值复制到成功(200类)寄存器响应中的路径头字段中。在归属代理和注册器不在同一位置的情况下,注册器可以对存储的路径向量应用本地确定的变换。

If a registrar receives a REGISTER request containing a Path header field and there is no indication of support for the extension in the UA (via a Supported header field), the registrar must rely on local policy in determining how to treat this request. The recommended policy is for the registrar to reject the request with a 420 "Bad Extension" response indicating the Path extension. This approach allows the UA to detect that an intermediate proxy has inappropriately added a Path header field. However, the Path mechanism should technically work in the absence of UA support (at some compromise to security), so some registrars MAY choose to support the extension in the absence of a Supported header field value in the request.

如果注册器接收到包含路径头字段的注册请求,并且UA中没有支持扩展的指示(通过支持的头字段),则注册器必须依赖本地策略来确定如何处理该请求。建议的策略是注册器使用420“坏扩展”响应拒绝请求,该响应指示路径扩展。这种方法允许UA检测到中间代理不适当地添加了路径头字段。然而,路径机制在技术上应该在没有UA支持的情况下工作(在某种程度上危及安全性),因此一些注册者可以选择在请求中没有支持的报头字段值的情况下支持扩展。

5.4 Procedures at the Home Proxy
5.4 家庭代理的程序

In the common SIP model, there is a home proxy associated with the registrar for a user. Each incoming request targeted to the public address-of-record for the user is routed to this proxy, which consults the registrar's database in order to determine the contact to which the request should be retargeted. The home proxy, in its basic mode of operation, rewrites the request-URI from the incoming

在公共SIP模型中,存在与用户的注册器相关联的归属代理。每个以用户记录的公共地址为目标的传入请求都被路由到此代理,该代理将咨询注册官的数据库,以确定请求应重定向到的联系人。主代理在其基本操作模式下,重写来自传入代理的请求URI

request with the value of the registered contact and retransmits the request.

使用已注册联系人的值进行请求,然后重新传输该请求。

With the addition of Path, the home proxy also copies the stored path vector associated with the specific contact in the registrar database into the Route header field of the outgoing request as a preloaded route. This causes the outgoing request to transit the proxies that were included in the Path header field of the REGISTER request.

通过添加路径,归属代理还将与注册器数据库中的特定联系人相关联的存储路径向量作为预加载的路由复制到传出请求的路由头字段中。这会导致传出请求传输寄存器请求的路径头字段中包含的代理。

In normal processing, the home proxy is the "terminal point" for the user's address-of-record (AOR). Consequentially, the Route header field on the incoming request will have been exhausted in reaching the home proxy. If it isn't, then things get interesting. In the most common case, the home proxy generates the outgoing Route header field by inserting the stored path vector ahead of the Route header field values contained in the incoming request. This procedure may be altered by a local policy at the home proxy.

在正常处理中,主代理是用户记录地址(AOR)的“终点”。因此,传入请求上的Route header字段将在到达主代理时耗尽。如果不是,事情就会变得有趣。在最常见的情况下,主代理通过在传入请求中包含的路由头字段值之前插入存储的路径向量来生成传出路由头字段。本地代理的本地策略可能会更改此过程。

Loose routes may interact with routing policy in interesting ways. The specifics of how the stored path vector 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 stored path vector is appended to any locally configured route needed to egress the service cluster. The service proxy (or registrar, as noted earlier) MAY also transform the stored path vector as needed to provide correct functionality. Systems designers must match the Path recording policy of their nodes with the routing policy in order to get a workable system.

松散路由可能以有趣的方式与路由策略交互。存储的路径向量如何与任何本地所需的默认路由和本地策略集成的细节取决于实现。例如,一些设备将使用本地配置的显式松散路由到达下一跳代理,而其他设备将使用默认的出站代理路由规则。但是,为了使结果正常工作,组合必须在本地环境中提供有效的路由。通常,存储的路径向量被附加到离开服务集群所需的任何本地配置的路由。服务代理(或注册器,如前所述)还可以根据需要变换存储的路径向量以提供正确的功能。系统设计者必须将其节点的路径记录策略与路由策略相匹配,以获得可行的系统。

5.5 Examples of Usage
5.5 用法示例

Note that some header fields (e.g. Content-Length) and session descriptions are omitted to provide a shorter and hopefully more readable presentation. The node marked REGISTRAR is a registrar and a proxy and serves as a home proxy. Thus, in the DNS the domain EXAMPLEHOME.COM points to the same host as REGISTRAR.EXAMPLEHOME.COM.

请注意,省略了一些标题字段(例如内容长度)和会话描述,以提供更短、更具可读性的表示。标记为register的节点是一个注册器和一个代理,用作主代理。因此,在DNS中,域EXAMPLEHOME.COM指向与registrator.EXAMPLEHOME.COM相同的主机。

5.5.1 Example of Mechanism in REGISTER Transaction
5.5.1 注册事务中的机制示例

As an example, we use the scenario from the Background section:

例如,我们使用背景部分的场景:

   UA1----P1-----P2----P3-----REGISTRAR
        
   UA1----P1-----P2----P3-----REGISTRAR
        

In this example, UA1 sends a REGISTER request to REGISTRAR. This request transits its default outbound proxy P1, an intermediate proxy P2, and the firewall proxy for the home domain, P3, before reaching REGISTRAR. Due to network topology and operational policy, P1 and and P3 need to be transited by requests from REGISTRAR or other nodes in the home network targeted to UA1. P2 does not. P1 and P3 have been configured to include themselves in Path header fields on REGISTER requests that they process. UA1 has a current IP address of "192.0.2.4".

在本例中,UA1向注册器发送注册请求。在到达注册器之前,该请求传输其默认出站代理P1、中间代理P2和主域的防火墙代理P3。由于网络拓扑和操作策略,P1和P3需要通过来自注册器或家庭网络中针对UA1的其他节点的请求进行传输。P2没有。P1和P3已配置为将其自身包含在其处理的寄存器请求的路径头字段中。UA1的当前IP地址为“192.0.2.4”。

Message sequence for REGISTER with Path:

具有路径的寄存器的消息序列:

F1 Register UA1 -> P1

F1寄存器UA1->P1

REGISTER sip:REGISTRAR.EXAMPLEHOME.COM SIP/2.0 Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7 To: UA1 <sip:UA1@EXAMPLEHOME.COM> From: UA1 <sip:UA1@EXAMPLEHOME.COM>;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: <sip:UA1@192.0.2.4> Supported: path . . .

通过sip/2.0/UDP 192.0.2.4:5060注册sip:REGISTER.EXAMPLEHOME.COM sip/2.0;分支=z9hG4bKnashds7至:UA1<sip:UA1@EXAMPLEHOME.COM>来自:UA1<sip:UA1@EXAMPLEHOME.COM>;tag=456248呼叫ID:843817637684230@998sdasdh09CSeq:1826注册联系人:<sip:UA1@192.0.2.4>支持:路径。

F2 Register P1 -> P2

F2寄存器P1->P2

REGISTER sip:REGISTRAR.EXAMPLEHOME.COM SIP/2.0 Via: SIP/2.0/UDP 112.68.155.4:5060;branch=z9hG4bK34ghi7ab04 Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7 To: UA1 <sip:UA1@EXAMPLEHOME.COM> From: UA1 <sip:UA1@EXAMPLEHOME.COM>;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: <sip:UA1@192.0.2.4> Supported: path Path: <sip:P1.EXAMPLEVISITED.COM;lr> . . .

通过sip/2.0/UDP 112.68.155.4:5060注册sip:REGISTER.EXAMPLEHOME.COM sip/2.0;branch=z9hG4bK34ghi7ab04通过:SIP/2.0/UDP 192.0.2.4:5060;分支=z9hG4bKnashds7至:UA1<sip:UA1@EXAMPLEHOME.COM>来自:UA1<sip:UA1@EXAMPLEHOME.COM>;tag=456248呼叫ID:843817637684230@998sdasdh09CSeq:1826注册联系人:<sip:UA1@192.0.2.4>支持:路径路径:<sip:P1.EXAMPLEVISITED.COM;lr>。

Note: P1 has added itself to the Path.

注意:P1已将自身添加到路径中。

F3 Register P2 -> P3

F3寄存器P2->P3

REGISTER sip:REGISTRAR.EXAMPLEHOME.COM SIP/2.0 Via: SIP/2.0/UDP 178.73.76.230:5060;branch=z9hG4bKiokioukju908 Via: SIP/2.0/UDP 112.68.155.4:5060;branch=z9hG4bK34ghi7ab04 Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7 To: UA1 <sip:UA1@EXAMPLEHOME.COM> From: UA1 <sip:UA1@EXAMPLEHOME.COM>;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: <sip:UA1@192.0.2.4> Supported: path Path: <sip:P1.EXAMPLEVISITED.COM;lr> . . .

通过sip/2.0/UDP 178.73.76.230:5060注册sip:REGISTER.EXAMPLEHOME.COM sip/2.0;branch=Z9HG4BKIOOKJU908通过:SIP/2.0/UDP 112.68.155.4:5060;branch=z9hG4bK34ghi7ab04通过:SIP/2.0/UDP 192.0.2.4:5060;分支=z9hG4bKnashds7至:UA1<sip:UA1@EXAMPLEHOME.COM>来自:UA1<sip:UA1@EXAMPLEHOME.COM>;tag=456248呼叫ID:843817637684230@998sdasdh09CSeq:1826注册联系人:<sip:UA1@192.0.2.4>支持:路径路径:<sip:P1.EXAMPLEVISITED.COM;lr>。

Note: P2 did NOT add itself to the Path.

注意:P2未将自身添加到路径中。

F4 Register P3 -> REGISTRAR

F4寄存器P3->寄存器

REGISTER sip:REGISTRAR.EXAMPLEHOME.COM SIP/2.0 Via: SIP/2.0/UDP 19.31.97.3:5060;branch=z9hG4bKp3wer654363 Via: SIP/2.0/UDP 178.73.76.230:5060;branch=z9hG4bKiokioukju908 Via: SIP/2.0/UDP 112.68.155.4:5060;branch=z9hG4bK34ghi7ab04 Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7 To: UA1 <sip:UA1@EXAMPLEHOME.COM> From: UA1 <sip:UA1@EXAMPLEHOME.COM>;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: <sip:UA1@192.0.2.4> Supported: path Path: <sip:P3.EXAMPLEHOME.COM;lr>,<sip:P1.EXAMPLEVISITED.COM;lr> . . .

通过sip/2.0/UDP 19.31.97.3:5060注册sip:REGISTER.EXAMPLEHOME.COM sip/2.0;branch=z9hG4bKp3wer654363 Via:SIP/2.0/UDP 178.73.76.230:5060;branch=Z9HG4BKIOOKJU908通过:SIP/2.0/UDP 112.68.155.4:5060;branch=z9hG4bK34ghi7ab04通过:SIP/2.0/UDP 192.0.2.4:5060;分支=z9hG4bKnashds7至:UA1<sip:UA1@EXAMPLEHOME.COM>来自:UA1<sip:UA1@EXAMPLEHOME.COM>;tag=456248呼叫ID:843817637684230@998sdasdh09CSeq:1826注册联系人:<sip:UA1@192.0.2.4>支持:路径路径:<sip:P3.EXAMPLEHOME.COM;lr>,<sip:P1.EXAMPLEVISITED.COM;lr>。

Note: P3 added itself to the Path.

注意:P3将自身添加到路径中。

F5 REGISTRAR executes Register

F5寄存器执行寄存器

      REGISTRAR Stores:
      For UA1@EXAMPLEHOME.COM
      Contact: <sip:UA1@192.0.2.4>
      Supported: path
      Path: <sip:P3.EXAMPLEHOME.COM;lr>,<sip:P1.EXAMPLEVISITED.COM;lr>
        
      REGISTRAR Stores:
      For UA1@EXAMPLEHOME.COM
      Contact: <sip:UA1@192.0.2.4>
      Supported: path
      Path: <sip:P3.EXAMPLEHOME.COM;lr>,<sip:P1.EXAMPLEVISITED.COM;lr>
        

F6 Register Response REGISTRAR -> P3

F6寄存器响应注册器->P3

SIP/2.0 200 OK Via: SIP/2.0/UDP 19.31.97.3:5060;branch=z9hG4bKp3wer654363 Via: SIP/2.0/UDP 178.73.76.230:5060;branch=z9hG4bKiokioukju908 Via: SIP/2.0/UDP 112.68.155.4:5060;branch=z9hG4bK34ghi7ab04 Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7 To: UA1 <sip:UA1@EXAMPLEHOME.COM>;tag=251077 From: UA1 <sip:UA1@EXAMPLEHOME.COM>;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: <sip:UA1@192.0.2.4> Supported: path Path: <sip:P3.EXAMPLEHOME.COM;lr>,<sip:P1.EXAMPLEVISITED.COM;lr> . . .

SIP/2.0 200 OK Via:SIP/2.0/UDP 19.31.97.3:5060;branch=z9hG4bKp3wer654363 Via:SIP/2.0/UDP 178.73.76.230:5060;branch=Z9HG4BKIOOKJU908通过:SIP/2.0/UDP 112.68.155.4:5060;branch=z9hG4bK34ghi7ab04通过:SIP/2.0/UDP 192.0.2.4:5060;分支=z9hG4bKnashds7至:UA1<sip:UA1@EXAMPLEHOME.COM>;标签=251077来自:UA1<sip:UA1@EXAMPLEHOME.COM>;tag=456248呼叫ID:843817637684230@998sdasdh09CSeq:1826注册联系人:<sip:UA1@192.0.2.4>支持:路径路径:<sip:P3.EXAMPLEHOME.COM;lr>,<sip:P1.EXAMPLEVISITED.COM;lr>。

Note: The Path header field in the response is identical to the one received in the REGISTER request.

注意:响应中的Path header字段与寄存器请求中接收的字段相同。

F7 Register Response P3 -> P2

F7寄存器响应P3->P2

SIP/2.0 200 OK Via: SIP/2.0/UDP 178.73.76.230:5060;branch=z9hG4bKiokioukju908 Via: SIP/2.0/UDP 112.68.155.4:5060;branch=z9hG4bK34ghi7ab04 Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7 To: UA1 <sip:UA1@EXAMPLEHOME.COM>;tag=251077 From: UA1 <sip:UA1@EXAMPLEHOME.COM>;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: <sip:UA1@192.0.2.4> Supported: path Path: <sip:P3.EXAMPLEHOME.COM;lr>,<sip:P1.EXAMPLEVISITED.COM;lr> . . .

SIP/2.0 200正常通过:SIP/2.0/UDP 178.73.76.230:5060;branch=Z9HG4BKIOOKJU908通过:SIP/2.0/UDP 112.68.155.4:5060;branch=z9hG4bK34ghi7ab04通过:SIP/2.0/UDP 192.0.2.4:5060;分支=z9hG4bKnashds7至:UA1<sip:UA1@EXAMPLEHOME.COM>;标签=251077来自:UA1<sip:UA1@EXAMPLEHOME.COM>;tag=456248呼叫ID:843817637684230@998sdasdh09CSeq:1826注册联系人:<sip:UA1@192.0.2.4>支持:路径路径:<sip:P3.EXAMPLEHOME.COM;lr>,<sip:P1.EXAMPLEVISITED.COM;lr>。

F8 Register Response P2 -> P1

F8寄存器响应P2->P1

SIP/2.0 200 OK Via: SIP/2.0/UDP 112.68.155.4:5060;branch=z9hG4bK34ghi7ab04 Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7 To: UA1 <sip:UA1@EXAMPLEHOME.COM>;tag=251077 From: UA1 <sip:UA1@EXAMPLEHOME.COM>;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: <sip:UA1@192.0.2.4> Supported: path Path: <sip:P3.EXAMPLEHOME.COM;lr>,<sip:P1.EXAMPLEVISITED.COM;lr> . . .

SIP/2.0 200 OK Via:SIP/2.0/UDP 112.68.155.4:5060;branch=z9hG4bK34ghi7ab04通过:SIP/2.0/UDP 192.0.2.4:5060;分支=z9hG4bKnashds7至:UA1<sip:UA1@EXAMPLEHOME.COM>;标签=251077来自:UA1<sip:UA1@EXAMPLEHOME.COM>;tag=456248呼叫ID:843817637684230@998sdasdh09CSeq:1826注册联系人:<sip:UA1@192.0.2.4>支持:路径路径:<sip:P3.EXAMPLEHOME.COM;lr>,<sip:P1.EXAMPLEVISITED.COM;lr>。

F9 Register Response P1 -> UA1

F9寄存器响应P1->UA1

SIP/2.0 200 OK Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7 To: UA1 <sip:UA1@EXAMPLEHOME.COM>;tag=251077 From: UA1 <sip:UA1@EXAMPLEHOME.COM>;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: <sip:UA1@192.0.2.4> Supported: path Path: <sip:P3.EXAMPLEHOME.COM;lr>,<sip:P1.EXAMPLEVISITED.COM;lr> . . .

SIP/2.0 200 OK Via:SIP/2.0/UDP 192.0.2.4:5060;分支=z9hG4bKnashds7至:UA1<sip:UA1@EXAMPLEHOME.COM>;标签=251077来自:UA1<sip:UA1@EXAMPLEHOME.COM>;tag=456248呼叫ID:843817637684230@998sdasdh09CSeq:1826注册联系人:<sip:UA1@192.0.2.4>支持:路径路径:<sip:P3.EXAMPLEHOME.COM;lr>,<sip:P1.EXAMPLEVISITED.COM;lr>。

5.5.2 Example of Mechanism in INVITE Transaction
5.5.2 INVITE事务中的机制示例

This example shows the message sequence for an INVITE transaction originating from UA2 eventually arriving at UA1. REGISTRAR inserts a preloaded Route toward UA1 and retargets the request by replacing the request URI with the registered Contact. It then sends the retargeted INVITE along the Path towards UA1. Note that this example introduces foreign user agent UA2 (address "71.91.180.10") and foreign domain FOREIGN.ELSEWHERE.ORG. We have extended the diagram from the previous example by adding UA2, and by showing P2 out-of-line indicating that it did not include itself in the path during registration.

此示例显示源自UA2并最终到达UA1的INVITE事务的消息序列。注册器向UA1插入一条预加载的路由,并通过将请求URI替换为已注册的联系人来重新确定请求的目标。然后,它沿着路径向UA1发送重定目标的邀请。请注意,此示例介绍了外国用户代理UA2(地址“71.91.180.10”)和foreign domain foreign.where.ORG。我们通过添加UA2扩展了上一个示例中的关系图,并通过显示P2,指出其在注册过程中没有包含在路径中。

Scenario

脚本

         UA1----P1---------P3-----REGISTRAR
                     |               |
                     P2              |
                                     |
         UA2--------------------------
        
         UA1----P1---------P3-----REGISTRAR
                     |               |
                     P2              |
                                     |
         UA2--------------------------
        

Message sequence for INVITE using Path:

使用路径的INVITE的消息序列:

F1 Invite UA2 -> REGISTRAR

F1邀请UA2->注册

INVITE UA1@EXAMPLEHOME.COM SIP/2.0 Via: SIP/2.0/UDP 71.91.180.10:5060;branch=z9hG4bKe2i95c5st3R To: UA1 <sip:UA1@EXAMPLEHOME.COM> From: UA2 <sip:UA2@FOREIGN.ELSEWHERE.ORG>;tag=224497 Call-ID: 48273181116@71.91.180.10 CSeq: 29 INVITE Contact: <sip:UA2@71.91.180.10> . . .

邀请UA1@EXAMPLEHOME.COMSIP/2.0 Via:SIP/2.0/UDP 71.91.180.10:5060;分支=z9hG4bKe2i95c5st3R至:UA1<sip:UA1@EXAMPLEHOME.COM>发件人:UA2<sip:UA2@FOREIGN.ELSEWHERE.ORG>;tag=224497呼叫ID:48273181116@71.91.180.10CSeq:29邀请联系人:<sip:UA2@71.91.180.10> . . .

F2 REGISTRAR processing

注册处理

      REGISTRAR looks up name "UA1@EXAMPLEHOME.COM" and returns:
       - Contact = <sip:UA1@192.0.2.4>
       - Path vector = <sip:P3.EXAMPLEHOME.COM;lr>,
                       <sip:P1.EXAMPLEVISITED.COM;lr>
        
      REGISTRAR looks up name "UA1@EXAMPLEHOME.COM" and returns:
       - Contact = <sip:UA1@192.0.2.4>
       - Path vector = <sip:P3.EXAMPLEHOME.COM;lr>,
                       <sip:P1.EXAMPLEVISITED.COM;lr>
        

Note: The Contact replaces the request-URI. The path vector is pushed onto the Route stack (preloaded Route) of the outgoing INVITE request. The topmost Route is used for making the routing decision (in conjunction with local policy).

注意:联系人将替换请求URI。路径向量被推送到传出INVITE请求的路由堆栈(预加载的路由)上。最上面的路由用于做出路由决策(与本地策略结合使用)。

F3 Invite REGISTRAR -> P3

F3邀请注册者->P3

INVITE UA1@192.0.2.4 SIP/2.0 Via: SIP/2.0/UDP 143.70.6.83:5060;branch=z9hG4bKlj25C107a7b176 Via: SIP/2.0/UDP 71.91.180.10:5060;branch=z9hG4bKe2i95c5st3R To: UA1 <sip:UA1@EXAMPLEHOME.COM> From: UA2 <sip:UA2@FOREIGN.ELSEWHERE.ORG>;tag=224497 Call-ID: 48273181116@71.91.180.10 CSeq: 29 INVITE Contact: <sip:UA2@71.91.180.10> Route: <sip:P3.EXAMPLEHOME.COM;lr>,<sip:P1.EXAMPLEVISITED.COM;lr> . . .

邀请UA1@192.0.2.4SIP/2.0 Via:SIP/2.0/UDP 143.70.6.83:5060;branch=z9hG4bKlj25C107a7b176 Via:SIP/2.0/UDP 71.91.180.10:5060;分支=z9hG4bKe2i95c5st3R至:UA1<sip:UA1@EXAMPLEHOME.COM>发件人:UA2<sip:UA2@FOREIGN.ELSEWHERE.ORG>;tag=224497呼叫ID:48273181116@71.91.180.10CSeq:29邀请联系人:<sip:UA2@71.91.180.10>路线:<sip:P3.EXAMPLEHOME.COM;lr>,<sip:P1.EXAMPLEVISITED.COM;lr>。

Note: In this example REGISTRAR does not want to stay on the Route and therefore does not insert a Record-Route.

注意:在本例中,注册员不想停留在路由上,因此不插入记录路由。

F4 Invite P3 -> P1

F4邀请P3->P1

INVITE UA1@192.0.2.4 SIP/2.0 Via: SIP/2.0/UDP 19.31.97.3:5060;branch=z9hG4bKjasg7li7nc9e Via: SIP/2.0/UDP 143.70.6.83:5060;branch=z9hG4bKlj25C107a7b176 Via: SIP/2.0/UDP 71.91.180.10:5060;branch=z9hG4bKe2i95c5st3R To: UA1 <sip:UA1@EXAMPLEHOME.COM> From: UA2 <sip:UA2@FOREIGN.ELSEWHERE.ORG>;tag=224497 Call-ID: 48273181116@71.91.180.10 CSeq: 29 INVITE Contact: <sip:UA2@71.91.180.10> Record-Route: <sip:P3.EXAMPLEHOME.COM;lr> Route: <sip:P1.EXAMPLEVISITED.COM;lr> . . .

邀请UA1@192.0.2.4SIP/2.0 Via:SIP/2.0/UDP 19.31.97.3:5060;branch=z9hG4bKjasg7li7nc9e通过:SIP/2.0/UDP 143.70.6.83:5060;branch=z9hG4bKlj25C107a7b176 Via:SIP/2.0/UDP 71.91.180.10:5060;分支=z9hG4bKe2i95c5st3R至:UA1<sip:UA1@EXAMPLEHOME.COM>发件人:UA2<sip:UA2@FOREIGN.ELSEWHERE.ORG>;tag=224497呼叫ID:48273181116@71.91.180.10CSeq:29邀请联系人:<sip:UA2@71.91.180.10>记录路径:<sip:P3.EXAMPLEHOME.COM;lr>路由:<sip:P1.EXAMPLEVISITED.COM;lr>。

Note: P3 has added a Record-Route entry, indicating that it wants to be traversed by future messages in this dialog.

注意:P3添加了一个记录路由条目,表示它希望在此对话框中被将来的消息遍历。

F5 Invite P1 -> UA1

F5邀请P1->UA1

INVITE UA1@192.0.2.4 SIP/2.0 Via: SIP/2.0/UDP 112.68.155.4:5060;branch=z9hG4bKk5l1833o43p Via: SIP/2.0/UDP 19.31.97.3:5060;branch=z9hG4bKjasg7li7nc9e Via: SIP/2.0/UDP 143.70.6.83:5060;branch=z9hG4bKlj25C107a7b176 Via: SIP/2.0/UDP 71.91.180.10:5060;branch=z9hG4bKe2i95c5st3R To: UA1 <sip:UA1@EXAMPLEHOME.COM> From: UA2 <sip:UA2@FOREIGN.ELSEWHERE.ORG>;tag=224497 Call-ID: 48273181116@71.91.180.10 CSeq: 29 INVITE Contact: <sip:UA2@71.91.180.10> Record-Route: <sip:P1.EXAMPLEVISITED.COM;lr> Record-Route: <sip:P3.EXAMPLEHOME.COM;lr> . . .

邀请UA1@192.0.2.4SIP/2.0 Via:SIP/2.0/UDP 112.68.155.4:5060;branch=z9hG4bKk5l1833o43p通过:SIP/2.0/UDP 19.31.97.3:5060;branch=z9hG4bKjasg7li7nc9e通过:SIP/2.0/UDP 143.70.6.83:5060;branch=z9hG4bKlj25C107a7b176 Via:SIP/2.0/UDP 71.91.180.10:5060;分支=z9hG4bKe2i95c5st3R至:UA1<sip:UA1@EXAMPLEHOME.COM>发件人:UA2<sip:UA2@FOREIGN.ELSEWHERE.ORG>;tag=224497呼叫ID:48273181116@71.91.180.10CSeq:29邀请联系人:<sip:UA2@71.91.180.10>记录路径:<sip:P1.EXAMPLEVISITED.COM;lr>记录路由:<sip:P3.EXAMPLEHOME.COM;lr>。

Note: P1 has added a Record-Route entry, indicating that it wants to be traversed by future messages in this dialog.

注意:P1添加了一个记录路由条目,表示它希望在此对话框中被将来的消息遍历。

6. Security Considerations
6. 安全考虑

There are few security considerations for this document beyond those in SIP [1]. From a security perspective, the Path extension and its usage are identical to the Record-Route header field of basic SIP. Note that the transparency of the user expectations are preserved by returning the final Path to the originating UA -- that is, the UA is informed which additional proxies have been inserted into the path for the registration associated with that response.

除了SIP[1]中的安全注意事项外,本文档中的安全注意事项很少。从安全角度来看,路径扩展及其用法与基本SIP的记录路由头字段相同。注意,通过返回到发起UA的最终路径,用户期望的透明度得以保持——也就是说,UA被告知哪些额外的代理已经插入到与该响应相关联的注册路径中。

The Path header field accumulates information in a hop-by-hop manner during REGISTER processing. The return information is essentially end-to-end, that is, it is not altered by intermediate proxies. This leads to two slightly different security approaches.

路径头字段在寄存器处理期间以逐跳方式累积信息。返回信息基本上是端到端的,也就是说,它不会被中间代理更改。这导致了两种略有不同的安全方法。

6.1 Considerations in REGISTER Request Processing
6.1 注册请求处理中的注意事项

Information accumulated in REGISTER processing causes additional proxies to be included in future requests between the registrar's location and the UA. An attack that allowed an intruding proxy to add itself to this chain would allow the attacker to intercept future calls intended for the UA.

登记处处理过程中积累的信息会导致在登记处所在地和UA之间的未来请求中包括其他代理。允许入侵代理将其自身添加到此链的攻击将允许攻击者拦截未来针对UA的呼叫。

An attacker could conceivably alter the Path either by altering data "on the wire" or by other manipulations (such as impersonation) that would cause it to be included in the SIP routing chain (a "node insertion" attack). Altering data "on the wire" may be addressed adequately by the use of transport-layer integrity protection mechanisms such as TLS or IPSEC. Proxy insertion can be addressed by

攻击者可以通过改变“线路上”的数据或通过其他操作(如模拟)改变路径,从而导致该路径包含在SIP路由链中(“节点插入”攻击)。通过使用传输层完整性保护机制(如TLS或IPSEC),可以充分解决“在线”上的数据更改问题。代理插入可以通过

mutual authentication at the proxy layer, which can also be provided by TLS or IPSEC. The "sips:" URI class defined in [1] provides a mechanism by which a UA may request that intermediate proxies provide integrity protection and mutual authentication.

代理层的相互身份验证,也可以由TLS或IPSEC提供。[1]中定义的“sips:”URI类提供了一种机制,UA可以通过该机制请求中间代理提供完整性保护和相互认证。

Systems using the Path mechanism SHOULD use appropriate mechanisms (TLS, IPSEC, etc.) to provide message integrity and mutual authentication. UAs SHOULD use "sips:" to request transitive protection.

Systems using the Path mechanism SHOULD use appropriate mechanisms (TLS, IPSEC, etc.) to provide message integrity and mutual authentication. UAs SHOULD use "sips:" to request transitive protection.translate error, please retry

The registering UA SHOULD use S/MIME mechanisms to provide a protected copy of the original request to the registrar. In this case, the UA SHOULD include a Supported header field with a value indicating support for the Path extension in the protected copy. Registrars receiving such as request MUST honor the Path extension only if support is indicated in the protected header field. Further, they SHOULD compare the unprotected Supported header field with the protected Supported header field and take appropriate action in the event that an intermediate has altered the message to indicate support for Path when it was not indicated by the requesting UA.

注册UA应使用S/MIME机制向注册官提供原始请求的受保护副本。在这种情况下,UA应包括一个受支持的标头字段,该字段的值指示对受保护副本中的路径扩展的支持。只有在受保护的标头字段中指示支持时,接收此类请求的注册者才必须遵守路径扩展。此外,他们应将未受保护的受支持标头字段与受保护的受支持标头字段进行比较,并在中间层更改消息以指示对路径的支持(请求UA未指示该消息时)时采取适当措施。

6.2 Considerations in REGISTER Response Processing
6.2 寄存器响应处理中的注意事项

The data returned to the UA by the Path header field in the response to the REGISTER request is there to provide openness to the UA. The registrar is telling the UA, "These are the intermediate proxies that will be included on future requests to you processed through me". By inspection of this header field, the UA may be able to detect node insertion attacks that involve inserting a proxy into the SIP routing chain. S/MIME techniques may be used to prevent alteration of this header field by intermediate proxies during response processing.

在对注册请求的响应中,Path header字段返回给UA的数据用于向UA提供开放性。注册官告诉UA,“这些是中间代理,将包括在未来通过我处理的向您提出的请求中”。通过检查该报头字段,UA可能能够检测涉及将代理插入SIP路由链的节点插入攻击。可以使用S/MIME技术来防止中间代理在响应处理期间更改此头字段。

As specified, there is no requirement for arbitrary proxies between the UA and the registrar to modify the Path header field in the REGISTER response. Consequently, we may use an end-to-end protection technique. The S/MIME technique defined in [1] provides an effective mechanism. Using this technique, the registrar makes a copy of the complete response, signs it, and attaches it as a body to the response. The UA may then verify this response, assuring an unmodified Path header field is received.

如上所述,UA和注册器之间不需要任意代理来修改寄存器响应中的路径头字段。因此,我们可以使用端到端保护技术。[1]中定义的S/MIME技术提供了一种有效的机制。使用这种技术,注册者复制完整的响应,签名,并将其作为一个主体附加到响应上。UA随后可验证该响应,确保收到未修改的路径报头字段。

In addition to the hop-by-hop integrity protection and mutual authentication measures suggested for REGISTER request processing in the preceding section, systems using Path header fields SHOULD implement end-to-end protection using S/MIME. More specifically, registrars returning a Path header field SHOULD attach a signed S/MIME of the response, and UAs receiving a REGISTER response containing a Path header field SHOULD validate the message using the

除了上一节中为注册请求处理建议的逐跳完整性保护和相互认证措施外,使用路径头字段的系统还应使用S/MIME实现端到端保护。更具体地说,返回路径头字段的注册器应附加响应的签名S/MIME,接收包含路径头字段的注册器响应的UAs应使用

S/MIME technique. Furthermore, UAs receiving a Path header field in a REGISTER response SHOULD render it to the user, or (where feasible) check it programmatically.

S/MIME技术。此外,在寄存器响应中接收路径头字段的UAs应将其呈现给用户,或(在可行的情况下)以编程方式进行检查。

7. IANA Considerations
7. IANA考虑

This document defines the SIP extension header field "Path", which the IANA has added to the registry of SIP header fields defined in SIP [1].

本文档定义了SIP扩展头字段“Path”,IANA已将其添加到SIP[1]中定义的SIP头字段注册表中。

This document also defines the SIP option tag "path" which IANA has added to the registry of SIP option tags defined in SIP [1].

本文档还定义了IANA添加到SIP[1]中定义的SIP选项标记注册表中的SIP选项标记“路径”。

The following is the registration for the Path header field:

以下是路径头字段的注册:

RFC Number: RFC3327

RFC编号:RFC3327

Header Field Name: Path

标题字段名称:路径

Compact Form: none

紧凑型:无

The following is the registration for the path option tag:

以下是路径选项标记的注册:

RFC Number: RFC3327

RFC编号:RFC3327

Option Tag: path

选项标记:路径

8. Acknowledgements
8. 致谢

Min Huang and Stinson Mathai, who put together the original proposal in 3GPP for this mechanism, and worked out most of the 3GPP procedures in 24.229.

Min Huang和Stinson Mathai在3GPP中为该机制提出了最初的建议,并在24.229中制定了大部分3GPP程序。

Keith Drage, Bill Marshall, and Miguel Angel Garcia-Martin who argued with everybody a lot about the idea as well as helped refine the requirements.

Keith Drage、Bill Marshall和Miguel Angel Garcia Martin,他们与大家就这个想法进行了很多争论,并帮助完善了需求。

Juha Heinanen, who argued steadfastly against standardizing the function of discovering the home proxy with this technique in this document.

Juha Heinanen,他坚决反对在本文件中使用此技术标准化发现家庭代理的功能。

Normative References

规范性引用文件

[1] 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.

[1] Rosenberg,J.,Schulzrinne,H.,Camarillo,G.,Johnston,A.,Peterson,J.,Sparks,R.,Handley,M.和E.Schooler,“SIP:会话启动协议”,RFC 3261,2002年6月。

[2] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.

[2] Bradner,S.,“互联网标准过程——第3版”,BCP 9,RFC 2026,1996年10月。

[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[3] Bradner,S.,“RFC中用于表示需求水平的关键词”,BCP 14,RFC 2119,1997年3月。

[4] Postel, J. and J. Reynolds, "Instructions to RFC Authors", RFC 2223, October 1997.

[4] Postel,J.和J.Reynolds,“RFC作者须知”,RFC 2223,1997年10月。

Non-Normative References

非规范性引用文件

[5] Garcia-Martin, MA., "3GPP Requirements On SIP", Work in Progress.

[5] 马萨诸塞州加西亚·马丁,“3GPP对SIP的要求”,正在进行中。

[6] Mankin, A., "SIP Change Process", Work in Progress.

[6] Mankin,A.,“SIP变更流程”,正在进行中。

Authors' Addresses

作者地址

Dean Willis dynamicsoft Inc. 5100 Tennyson Parkway Suite 1200 Plano, TX 75028 US

迪安·威利斯动力软件有限公司,美国德克萨斯州普莱诺市坦尼森大道1200号5100室,邮编75028

   Phone: +1 972 473 5455
   EMail: dean.willis@softarmor.com
   URI:   http://www.dynamicsoft.com/
        
   Phone: +1 972 473 5455
   EMail: dean.willis@softarmor.com
   URI:   http://www.dynamicsoft.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/
        

Full Copyright Statement

完整版权声明

Copyright (C) The Internet Society (2002). All Rights Reserved.

版权所有(C)互联网协会(2002年)。版权所有。

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 assigns.

上述授予的有限许可是永久性的,互联网协会或其继承人或受让人不会撤销。

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编辑功能的资金目前由互联网协会提供。