Network Working Group F. Audet
Request for Comments: 5630 Skype Labs
Updates: 3261, 3608 October 2009
Category: Standards Track
Network Working Group F. Audet
Request for Comments: 5630 Skype Labs
Updates: 3261, 3608 October 2009
Category: Standards Track
The Use of the SIPS URI Scheme in the Session Initiation Protocol (SIP)
会话启动协议（SIP）中SIPS URI方案的使用
Abstract
摘要
This document provides clarifications and guidelines concerning the use of the SIPS URI scheme in the Session Initiation Protocol (SIP). It also makes normative changes to SIP.
本文档提供了有关在会话启动协议（SIP）中使用SIPS URI方案的说明和指南。它还对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 and License Notice
版权及许可证公告
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括《信托法律条款》第4.e节中所述的简化BSD许可文本，并且提供BSD许可中所述的代码组件时不提供任何担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Background ......................................................3
3.1. Models for Using TLS in SIP ................................3
3.1.1. Server-Provided Certificate .........................3
3.1.2. Mutual Authentication ...............................4
3.1.3. Using TLS with SIP Instead of SIPS ..................4
3.1.4. Usage of the transport=tls URI Parameter and
the TLS Via Parameter ...............................5
3.2. Detection of Hop-by-Hop Security ...........................6
3.3. The Problems with the Meaning of SIPS in RFC 3261 ..........7
4. Overview of Operations ..........................................9
4.1. Routing ...................................................11
5. Normative Requirements .........................................13
5.1. General User Agent Behavior ...............................13
5.1.1. UAC Behavior .......................................13
5.1.1.1. Registration ..............................14
5.1.1.2. SIPS in a Dialog ..........................15
5.1.1.3. Derived Dialogs and Transactions ..........15
5.1.1.4. GRUU ......................................16
5.1.2. UAS Behavior .......................................17
5.2. Registrar Behavior ........................................18
5.2.1. GRUU ...............................................18
5.3. Proxy Behavior ............................................18
5.4. Redirect Server Behavior ..................................20
6. Call Flows .....................................................21
6.1. Bob Registers His Contacts ................................22
6.2. Alice Calls Bob's SIPS AOR ................................27
6.3. Alice Calls Bob's SIP AOR Using TCP .......................36
6.4. Alice Calls Bob's SIP AOR Using TLS .......................50
7. Further Considerations .........................................51
8. Security Considerations ........................................52
9. IANA Considerations ............................................52
10. Acknowledgments ...............................................52
11. References ....................................................53
11.1. Normative References .....................................53
11.2. Informative References ...................................53
Appendix A. Bug Fixes for RFC 3261 ..............................55
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Background ......................................................3
3.1. Models for Using TLS in SIP ................................3
3.1.1. Server-Provided Certificate .........................3
3.1.2. Mutual Authentication ...............................4
3.1.3. Using TLS with SIP Instead of SIPS ..................4
3.1.4. Usage of the transport=tls URI Parameter and
the TLS Via Parameter ...............................5
3.2. Detection of Hop-by-Hop Security ...........................6
3.3. The Problems with the Meaning of SIPS in RFC 3261 ..........7
4. Overview of Operations ..........................................9
4.1. Routing ...................................................11
5. Normative Requirements .........................................13
5.1. General User Agent Behavior ...............................13
5.1.1. UAC Behavior .......................................13
5.1.1.1. Registration ..............................14
5.1.1.2. SIPS in a Dialog ..........................15
5.1.1.3. Derived Dialogs and Transactions ..........15
5.1.1.4. GRUU ......................................16
5.1.2. UAS Behavior .......................................17
5.2. Registrar Behavior ........................................18
5.2.1. GRUU ...............................................18
5.3. Proxy Behavior ............................................18
5.4. Redirect Server Behavior ..................................20
6. Call Flows .....................................................21
6.1. Bob Registers His Contacts ................................22
6.2. Alice Calls Bob's SIPS AOR ................................27
6.3. Alice Calls Bob's SIP AOR Using TCP .......................36
6.4. Alice Calls Bob's SIP AOR Using TLS .......................50
7. Further Considerations .........................................51
8. Security Considerations ........................................52
9. IANA Considerations ............................................52
10. Acknowledgments ...............................................52
11. References ....................................................53
11.1. Normative References .....................................53
11.2. Informative References ...................................53
Appendix A. Bug Fixes for RFC 3261 ..............................55
The meaning and usage of the SIPS URI scheme and of Transport Layer Security (TLS) [RFC5246] are underspecified in SIP [RFC3261] and have been a source of confusion for implementers.
SIPS URI方案和传输层安全性（TLS）[RFC5246]的含义和用法在SIP[RFC3261]中没有明确规定，这给实施者带来了困惑。
This document provides clarifications and guidelines concerning the use of the SIPS URI scheme in the Session Initiation Protocol (SIP). It also makes normative changes to SIP (including both [RFC3261] and [RFC3608].
本文档提供了有关在会话启动协议（SIP）中使用SIPS URI方案的说明和指南。它还对SIP进行了规范性修改（包括[RFC3261]和[RFC3608]。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
This section describes briefly the usage of TLS in SIP.
本节简要介绍了TLS在SIP中的用法。
In this model, only the TLS server provides a certificate during the TLS handshake. This is applicable only between a user agent (UA) and a proxy, where the UA is the TLS client and the proxy is the TLS server, and hence the UA uses TLS to authenticate the proxy but the proxy does not use TLS to authenticate the UA. If the proxy needs to authenticate the UA, this can be achieved by SIP HTTP digest authentication. This directionality implies that the TLS connection always needs to be set up by the UA (e.g., during the registration phase). Since SIP allows for requests in both directions (e.g., an incoming call), the UA is expected to keep the TLS connection alive, and that connection is expected to be reused for both incoming and outgoing requests.
在此模型中，只有TLS服务器在TLS握手期间提供证书。这仅适用于用户代理（UA）和代理之间，其中UA是TLS客户端，代理是TLS服务器，因此UA使用TLS对代理进行身份验证，但代理不使用TLS对UA进行身份验证。如果代理需要对UA进行身份验证，则可以通过SIP HTTP摘要身份验证来实现。这种方向性意味着TLS连接始终需要由UA设置（例如，在注册阶段）。由于SIP允许双向请求（例如，传入呼叫），UA应保持TLS连接处于活动状态，并且该连接应可用于传入和传出请求。
This solution of having the UA always initiate and keep alive the connection also solves the Network Address Translation (NAT) and firewall problem as it ensures that responses and further requests will always be deliverable on the existing connection.
这种让UA始终启动并保持连接的解决方案还解决了网络地址转换（NAT）和防火墙问题，因为它确保了响应和进一步的请求始终可以在现有连接上交付。
[RFC5626] provides the mechanism for initiating and maintaining outbound connections in a standard interoperable way.
[RFC5626]提供了以标准互操作方式启动和维护出站连接的机制。
In this model, both the TLS client and the TLS server provide a certificate in the TLS handshake phase. When used between a UA and a proxy (or between two UAs), this implies that a UA is in possession of a certificate. When sending a SIP request when there is not already a suitable TLS connection in place, a user agent client (UAC) takes on the role of TLS client in establishing a new TLS connection. When establishing a TLS connection for receipt of a SIP request, a user agent server (UAS) takes on the role of TLS server. Because in SIP a UA or a proxy acts both as UAC and UAS depending on if it is sending or receiving requests, the symmetrical nature of mutual TLS is very convenient. This allows for TLS connections to be set up or torn down at will and does not rely on keeping the TLS connection alive for further requests.
在此模型中，TLS客户端和TLS服务器都在TLS握手阶段提供证书。当在UA和代理（或两个UA）之间使用时，这意味着UA拥有证书。当在没有合适的TLS连接时发送SIP请求时，用户代理客户端（UAC）在建立新的TLS连接时扮演TLS客户端的角色。当建立TLS连接以接收SIP请求时，用户代理服务器（UAS）扮演TLS服务器的角色。因为在SIP中，UA或代理根据其是发送还是接收请求同时充当UAC和UAS，所以相互TLS的对称性非常方便。这允许随意设置或拆除TLS连接，而不依赖于在进一步请求时保持TLS连接的活动状态。
However, there are some significant limitations.
然而，也存在一些重大限制。
The first obvious limitation is not with mutual authentication per se, but with the model where the underlying TCP connection can be established by either side, interchangeably, which is not possible in many environments. For examples, NATs and firewalls will often allow TCP connections to be established in one direction only. This includes most residential SIP deployments, for example. Mutual authentication can be used in those environments, but only if the connection is always started by the same side, for example, by using [RFC5626] as described in Section 3.1.1. Having to rely on [RFC5626] in this case negates many of the advantages of mutual authentication.
第一个明显的限制不是相互认证本身，而是模型，其中底层TCP连接可以由任意一方交换建立，这在许多环境中是不可能的。例如，NAT和防火墙通常只允许在一个方向上建立TCP连接。例如，这包括大多数住宅SIP部署。在这些环境中可以使用相互认证，但仅当连接始终由同一侧启动时，例如，如第3.1.1节所述，通过使用[RFC5626]启动。在这种情况下，必须依赖[RFC5626]否定了相互认证的许多优点。
The second significant limitation is that mutual authentication requires both sides to exchange a certificate. This has proven to be impractical in many environments, in particular for SIP UAs, because of the difficulties of setting up a certificate infrastructure for a wide population of users.
第二个重要限制是相互认证要求双方交换证书。这在许多环境中被证明是不切实际的，特别是对于SIP UAs，因为为大量用户设置证书基础设施是困难的。
For these reasons, mutual authentication is mostly used in server-to-server communications (e.g., between SIP proxies, or between proxies and gateways or media servers), and in environments where using certificates on both sides is possible (e.g., high-security devices used within an enterprise).
由于这些原因，相互认证主要用于服务器到服务器的通信（例如，SIP代理之间，或代理与网关或媒体服务器之间），以及在双方都可以使用证书的环境中（例如，企业内使用的高安全性设备）。
Because a SIPS URI implies that requests sent to the resource identified by it be sent over each SIP hop over TLS, SIPS URIs are not suitable for "best-effort TLS": they are only suitable for "TLS-only" requests. This is recognized in Section 26.2.2 of [RFC3261].
由于SIPS URI意味着发送到其标识的资源的请求将通过TLS上的每个SIP跃点发送，因此SIPS URI不适用于“尽力而为的TLS”：它们仅适用于“仅TLS”请求。[RFC3261]第26.2.2节对此进行了说明。
Users that distribute a SIPS URI as an address-of-record may elect to operate devices that refuse requests over insecure transports.
将SIPS URI作为记录地址分发的用户可以选择操作通过不安全传输拒绝请求的设备。
If one wants to use "best-effort TLS" for SIP, one just needs to use a SIP URI, and send the request over TLS.
如果希望对SIP使用“尽力而为的TLS”，只需要使用SIPURI，并通过TLS发送请求。
Using SIP over TLS is very simple. A UA opens a TLS connection and uses SIP URIs instead of SIPS URIs for all the header fields in a SIP message (From, To, Request-URI, Contact header field, Route, etc.). When TLS is used, the Via header field indicates TLS.
通过TLS使用SIP非常简单。UA打开TLS连接，并对SIP消息中的所有头字段（发件人、收件人、请求URI、联系人头字段、路由等）使用SIP URI而不是SIP URI。使用TLS时，Via标头字段指示TLS。
[RFC3261], Section 26.3.2.1, states:
[RFC3261]第26.3.2.1节规定：
When a UA comes online and registers with its local administrative domain, it SHOULD establish a TLS connection with its registrar (...). Once the registration has been accepted by the registrar, the UA SHOULD leave this TLS connection open provided that the registrar also acts as the proxy server to which requests are sent for users in this administrative domain. The existing TLS connection will be reused to deliver incoming requests to the UA that had just completed registration.
当UA联机并在其本地管理域注册时，它应与其注册官建立TLS连接（…）。注册官接受注册后，UA应保持此TLS连接打开，前提是注册官还充当代理服务器，向该管理域中的用户发送请求。现有的TLS连接将被重新使用，以向刚刚完成注册的UA发送传入请求。
[RFC5626] describes how to establish and maintain a TLS connection in environments where it can only be initiated by the UA.
[RFC5626]描述了如何在只能由UA启动的环境中建立和维护TLS连接。
Similarly, proxies can forward requests using TLS if they can open a TLS connection, even if the route set used SIP URIs instead of SIPS URIs. The proxies can insert Record-Route header fields using SIP URIs even if it uses TLS transport. [RFC3261], Section 26.3.2.2, explains how interdomain requests can use TLS.
类似地，如果代理可以打开TLS连接，则它们可以使用TLS转发请求，即使路由集使用SIP URI而不是SIPS URI。代理可以使用SIPURI插入记录路由头字段，即使它使用TLS传输。[RFC3261]第26.3.2.2节解释了域间请求如何使用TLS。
Some user agents, redirect servers, and proxies might have local policies that enforce TLS on all connections, independently of whether or not SIPS is used.
某些用户代理、重定向服务器和代理可能具有在所有连接上强制TLS的本地策略，而与是否使用SIPS无关。
3.1.4. Usage of the transport=tls URI Parameter and the TLS Via Parameter
3.1.4. transport=tls URI参数和tls Via参数的使用
[RFC3261], Section 26.2.2 deprecated the "transport=tls" URI transport parameter in SIPS or SIP URIs:
[RFC3261]，第26.2.2节不推荐SIPS或SIP URI中的“transport=tls”URI传输参数：
Note that in the SIPS URI scheme, transport is independent of TLS, and thus "sips:alice@atlanta.com;transport=TCP" and "sips:alice@atlanta.com;transport=sctp" are both valid (although note that UDP is not a valid transport for SIPS). The use of "transport=tls" has consequently been deprecated, partly because it was specific to a single hop of the request. This is a change since RFC 2543.
注意，在SIPS URI方案中，传输独立于TLS，因此“SIPS:alice@atlanta.com；传输=TCP“和”sips：alice@atlanta.com；transport=sctp“都是有效的（尽管请注意，UDP不是SIP的有效传输）。“transport=tls”的使用因此被弃用，部分原因是它特定于请求的单个跃点。这是自RFC 2543以来的变化。
The "tls" parameter has not been eliminated from the ABNF in [RFC3261], Section 25, since the parameter needs to remain in the ABNF for backward compatibility in order for parsers to be able to process the parameter correctly. The transport=tls parameter has never been defined in an RFC, but only in some of the Internet drafts between [RFC2543] and [RFC3261].
[RFC3261]第25节中的ABNF中没有删除“tls”参数，因为参数需要保留在ABNF中以实现向后兼容性，以便解析器能够正确处理参数。transport=tls参数从未在RFC中定义，但仅在[RFC2543]和[RFC3261]之间的一些Internet草稿中定义。
This specification does not make use of the transport=tls parameter.
本规范未使用transport=tls参数。
The reinstatement of the transport=tls parameter, or an alternative mechanism for indicating the use of the TLS on a single hop in a URI, is outside the scope of this specification.
transport=tls参数的恢复，或用于指示在URI中的单个跃点上使用tls的替代机制，不在本规范的范围内。
For Via header fields, the following transport protocols are defined in [RFC3261]: "UDP", "TCP", "TLS", "SCTP", and in [RFC4168]: "TLS-SCTP".
对于Via头字段，[RFC3261]：“UDP”、“TCP”、“TLS”、“SCTP”和[RFC4168]：“TLS-SCTP”中定义了以下传输协议。
The presence of a SIPS Request-URI does not necessarily indicate that the request was sent securely on each hop. So how does a UAS know if SIPS was used for the entire request path to secure the request end-to-end? Effectively, the UAS cannot know for sure. However, [RFC3261], Section 26.4.4, recommends how a UAS can make some checks to validate the security. Additionally, the History-Info header field [RFC4244] could be inspected for detecting retargeting from SIP and SIPS. Retargeting from SIP to SIPS by a proxy is an issue because it can leave the receiver of the request with the impression that the request was delivered securely on each hop, while in fact, it was not.
SIPS请求URI的存在并不一定表明请求在每个跃点上安全发送。那么UAS如何知道SIPS是否用于整个请求路径以保护请求端到端？事实上，UAS无法确定。但是，[RFC3261]第26.4.4节建议UAS如何进行一些检查以验证安全性。此外，可以检查历史信息报头字段[RFC4244]以检测来自SIP和SIP的重定目标。通过代理从SIP到SIP的重定目标是一个问题，因为它会给请求的接收者留下这样的印象，即请求在每个跃点上都安全地传递，而实际上并非如此。
To emphasize, all the checking can be circumvented by any proxies or back-to-back user agents (B2BUAs) on the path that do not follow the rules and recommendations of this specification and of [RFC3261].
需要强调的是，路径上的任何代理或背靠背用户代理（B2BUA）都可以绕过所有检查，这些代理或用户代理不遵循本规范和[RFC3261]的规则和建议。
Proxies can have their own policies regarding routing of requests to SIP or SIPS URIs. For example, some proxies in some environments can be configured to only route SIPS URIs. Some proxies can be configured to detect non-compliances and reject unsecure requests. For example, proxies could inspect Request-URIs, Path, Record-Route, To, From, Contact header fields, and Via header fields to enforce SIPS.
代理可以有自己关于将请求路由到SIP或SIPS URI的策略。例如，某些环境中的某些代理可以配置为仅路由SIPS URI。一些代理可以配置为检测不合规性并拒绝不安全的请求。例如，代理可以检查请求URI、路径、记录路由、收件人、发件人、联系人标头字段以及Via标头字段以强制执行SIP。
[RFC3261], Section 26.4.4, explains that S/MIME can also be used by the originating UAC to ensure that the original form of the To header field is carried end-to-end. While not specifically mentioned in [RFC3261], Section 26.4.4, this is meant to imply that [RFC3893] would be used to "tunnel" important header fields (such as To and
[RFC3261]第26.4.4节解释了原始UAC也可以使用S/MIME，以确保to报头字段的原始形式是端到端传输的。虽然[RFC3261]第26.4.4节中未明确提及，但这意味着[RFC3893]将用于“隧道”重要的标题字段（如to和
From) in an encrypted and signed S/MIME body, replicating the information in the SIP message, and allowing the UAS to validate the content of those important header fields. While this approach is certainly legal, a preferable approach is to use the SIP Identity mechanism defined in [RFC4474]. SIP Identity creates a signed identity digest, which includes, among other things, the Address of Record (AOR) of the sender (from the From header field) and the AOR of the original target (from the To header field).
从），在加密和签名的S/MIME正文中，复制SIP消息中的信息，并允许UAS验证这些重要头字段的内容。虽然这种方法肯定是合法的，但更好的方法是使用[RFC4474]中定义的SIP标识机制。SIP Identity创建一个签名的标识摘要，其中包括发送方的记录地址（AOR）（从from报头字段）和原始目标的AOR（从To报头字段）。
[RFC3261], Section 19.1, describes a SIPS URI as follows:
[RFC3261]第19.1节对SIPS URI的描述如下：
A SIPS URI specifies that the resource be contacted securely. This means, in particular, that TLS is to be used between the UAC and the domain that owns the URI. From there, secure communications are used to reach the user, where the specific security mechanism depends on the policy of the domain.
SIPS URI指定安全地联系资源。这特别意味着，将在UAC和拥有URI的域之间使用TLS。从那里，使用安全通信到达用户，其中特定的安全机制取决于域的策略。
Section 26.2.2 re-iterates it, with regards to Request-URIs:
第26.2.2节对请求URI进行了重新迭代：
When used as the Request-URI of a request, the SIPS scheme signifies that each hop over which the request is forwarded, until the request reaches the SIP entity responsible for the domain portion of the Request-URI, must be secured with TLS; once it reaches the domain in question it is handled in accordance with local security and routing policy, quite possibly using TLS for any last hop to a UAS. When used by the originator of a request (as would be the case if they employed a SIPS URI as the address-of-record of the target), SIPS dictates that the entire request path to the target domain be so secured.
当用作请求的请求URI时，SIPS方案表示在请求到达负责请求URI的域部分的SIP实体之前，转发请求的每个跃点都必须使用TLS进行保护；一旦它到达所讨论的域，它将根据本地安全和路由策略进行处理，很可能在到达UAS的任何最后一跳中使用TLS。当请求的发起者使用SIPS时（如果他们使用SIPS URI作为目标的记录地址，情况就是这样），SIPS指示到目标域的整个请求路径都是如此安全的。
Let's take the classic SIP trapezoid to explain the meaning of a sips:b@B URI. Instead of using real domain names like example.com and example.net, logical names like "A" and "B" are used, for clarity.
让我们以经典的SIP梯形图来解释sips的含义：b@B乌里。为了清晰起见，使用了“A”和“B”等逻辑名称，而不是使用example.com和example.net等真实域名。
.......................... ...........................
. . . .
. +-------+ . . +-------+ .
. | | . . | | .
. | Proxy |-----TLS---- | Proxy | .
. | A | . . | B | .
. | | . . | | .
. / +-------+ . . +-------+ \ .
. / . . \ .
. / . . \ .
. TLS . . Policy-based .
. / . . \ .
. / . . \ .
. / . . \ .
. +-------+ . . +-------+ .
. | | . . | | .
. | UAC a | . . | UAS b | .
. | | . . | | .
. +-------+ . . +-------+ .
. Domain A . . Domain B .
.......................... ...........................
.......................... ...........................
. . . .
. +-------+ . . +-------+ .
. | | . . | | .
. | Proxy |-----TLS---- | Proxy | .
. | A | . . | B | .
. | | . . | | .
. / +-------+ . . +-------+ \ .
. / . . \ .
. / . . \ .
. TLS . . Policy-based .
. / . . \ .
. / . . \ .
. / . . \ .
. +-------+ . . +-------+ .
. | | . . | | .
. | UAC a | . . | UAS b | .
. | | . . | | .
. +-------+ . . +-------+ .
. Domain A . . Domain B .
.......................... ...........................
SIP trapezoid with last-hop exception
带最后一跳异常的SIP梯形
According to [RFC3261], if a@A is sending a request to sips:b@B, the following applies:
根据[RFC3261]，如果a@A正在向sips发送请求：b@B，以下适用：
o TLS is required between UA a@A and Proxy A
o UA之间需要TLSa@A和代理A
o TLS is required between Proxy A and Proxy B
o 代理A和代理B之间需要TLS
o TLS is required between Proxy B and UA b@B, depending on local policy.
o 代理B和UA之间需要TLSb@B，视当地政策而定。
One can then wonder why TLS is mandatory between UA a@A and Proxy A but not between Proxy B and UA b@B. The main reason is that [RFC3261] was written before [RFC5626]. At that time, it was recognized that in many practical deployments, Proxy B might not be able to establish a TLS connection with UA b because only Proxy B would have a certificate to provide and UA b would not. Since UA b would be the TLS server, it would then not be able to accept the incoming TLS connection. The consequence is that an [RFC3261]- compliant UAS b, while it might not need to support TLS for incoming requests, will nevertheless have to support TLS for outgoing requests as it takes the UAC role. Contrary to what many believed erroneously, the last-hop exception was not created to allow for using a SIPS URI to address a UAS that does not support TLS: the last-hop exception was an attempt to allow for incoming requests to
人们可能想知道为什么UA之间必须使用TLSa@A和代理A，但不在代理B和UA之间b@B.主要原因是[RFC3261]是在[RFC5626]之前编写的。当时，人们认识到，在许多实际部署中，代理B可能无法与UA B建立TLS连接，因为只有代理B有证书可供提供，而UA B没有。由于UA b将是TLS服务器，因此它将无法接受传入的TLS连接。其结果是，符合[RFC3261]的UAS b虽然可能不需要为传入请求支持TLS，但仍必须为传出请求支持TLS，因为它承担UAC角色。与许多人错误地认为的相反，创建最后一跳异常并不是为了允许使用SIPS URI来寻址不支持TLS的UAS：最后一跳异常是为了允许传入的请求
not be transported over TLS when a SIPS URI is used, and it does not apply to outgoing requests. The rationale for this was somewhat flawed, and since then, [RFC5626] has provided a more satisfactory solution to this problem. [RFC5626] also solves the problem that if UA b is behind a NAT or firewall, Proxy B would not even be able to establish a TCP session in the first place.
当使用SIPS URI时，不能通过TLS传输，并且它不适用于传出请求。这样做的理由有些缺陷，从那时起，[RFC5626]为这个问题提供了更令人满意的解决方案。[RFC5626]还解决了一个问题，即如果UA b位于NAT或防火墙之后，那么代理b甚至无法首先建立TCP会话。
Furthermore, consider the problem of using SIPS inside a dialog. If a@A sends a request to b@B using a SIPS Request-URI, then, according to [RFC3261], Section 8.1.1.8, "the Contact header field MUST contain a SIPS URI as well". This means that b@B, upon sending a new Request within the dialog (e.g., a BYE or re-INVITE), will have to use a SIPS URI. If there is no Record-Route entry, or if the last Record-Route entry consists of a SIPS URI, this implies that b@B is expected to understand SIPS in the first place, and is required to also support TLS. If the last Record-Route entry however is a sip URI, then b would be able to send requests without using TLS (but b would still have to be able to handle SIPS schemes when parsing the message). In either case, the Request-URI in the request from b@B to B would be a SIPS URI.
此外，考虑在对话框中使用SIPS的问题。如果a@A向发送请求b@B使用SIPS请求URI，然后根据[RFC3261]第8.1.1.8节，“联系人标头字段也必须包含SIPS URI”。这意味着b@B在对话框中发送新请求（例如，拜拜或重新邀请）时，必须使用SIPS URI。如果没有记录路由条目，或者如果最后一个记录路由条目包含SIPS URI，这意味着b@B首先应了解SIPS，同时还应支持TLS。但是，如果最后一个记录路由条目是SIPURI，则b将能够在不使用TLS的情况下发送请求（但b在解析消息时仍必须能够处理SIPS方案）。在这两种情况下，来自的请求中的请求URIb@B到B将是SIPS URI。
Because of all the problems described in Section 3.3, this specification deprecates the last-hop exception when forwarding a request to the last hop (see Section 5.3). This will ensure that TLS is used on all hops all the way up to the remote target.
由于第3.3节中描述的所有问题，本规范在将请求转发到最后一个跃点时不推荐最后一个跃点异常（参见第5.3节）。这将确保TLS在一直到远程目标的所有跃点上使用。
.......................... ...........................
. . . .
. +-------+ . . +-------+ .
. | | . . | | .
. | Proxy |-----TLS---- | Proxy | .
. | A | . . | B | .
. | | . . | | .
. / +-------+ . . +-------+ \ .
. / . . \ .
. / . . \ .
. TLS . . TLS .
. / . . \ .
. / . . \ .
. / . . \ .
. +-------+ . . +-------+ .
. | | . . | | .
. | UAC a | . . | UAS b | .
. | | . . | | .
. +-------+ . . +-------+ .
. Domain A . . Domain B .
.......................... ...........................
.......................... ...........................
. . . .
. +-------+ . . +-------+ .
. | | . . | | .
. | Proxy |-----TLS---- | Proxy | .
. | A | . . | B | .
. | | . . | | .
. / +-------+ . . +-------+ \ .
. / . . \ .
. / . . \ .
. TLS . . TLS .
. / . . \ .
. / . . \ .
. / . . \ .
. +-------+ . . +-------+ .
. | | . . | | .
. | UAC a | . . | UAS b | .
. | | . . | | .
. +-------+ . . +-------+ .
. Domain A . . Domain B .
.......................... ...........................
SIP trapezoid without last-hop exception
无最后一跳异常的SIP梯形
The SIPS scheme implies transitive trust. Obviously, there is nothing that prevents proxies from cheating (see [RFC3261], Section 26.4.4). While SIPS is useful to request that a resource be contacted securely, it is not useful as an indication that a resource was in fact contacted securely. Therefore, it is not appropriate to infer that because an incoming request had a Request-URI (or even a To header field) containing a SIPS URI, that it necessarily guarantees that the request was in fact transmitted securely on each hop. Some have been tempted to believe that the SIPS scheme was equivalent to an HTTPS scheme in the sense that one could provide a visual indication to a user (e.g., a padlock icon) to the effect that the session is secured. This is obviously not the case, and therefore the meaning of a SIPS URI is not to be oversold. There is currently no mechanism to provide an indication of end-to-end security for SIP. Other mechanisms can provide a more concrete indication of some level of security. For example, SIP Identity [RFC4474] provides an authenticated identity mechanism and a domain-to-domain integrity protection mechanism.
SIPS方案意味着传递信任。显然，没有任何东西可以防止代理作弊（见[RFC3261]，第26.4.4节）。虽然SIPS对于请求安全地联系资源是有用的，但它对于指示资源实际上是安全地联系的并不有用。因此，推断由于传入请求具有包含SIPS URI的请求URI（甚至是to报头字段），因此它必须保证请求实际上在每个跃点上安全地传输是不合适的。有些人试图相信SIPS方案相当于HTTPS方案，因为可以向用户提供可视指示（例如挂锁图标），表明会话是安全的。显然情况并非如此，因此SIPS URI的含义不能被过度出售。目前没有为SIP提供端到端安全指示的机制。其他机制可以更具体地表明某种程度的安全性。例如，SIP Identity[RFC4474]提供了一种经过身份验证的身份机制和域到域的完整性保护机制。
Some have asked why is SIPS useful in a global open environment such as the Internet, if (when used in a Request-URI) it is not an absolute guarantee that the request will in fact be delivered over TLS on each hop? Why is SIPS any different from just using TLS transport with SIP? The difference is that using a SIPS URI in a
有人问，如果（在请求URI中使用）不能绝对保证请求将在每个跃点上通过TLS传递，那么SIPS为什么在全球开放环境（如互联网）中有用？为什么SIPS与仅将TLS传输与SIP一起使用有什么不同？区别在于在
Request-URI means that if you are instructing the network to use TLS over each hop and if it is not possible to reject the request, you would rather have the request fail than have the request delivered without TLS. Just using TLS with a SIP Request-URI instead of a SIPS Request-URI implies a "best-effort" service: the request can but need not be delivered over TLS on each hop.
请求URI意味着，如果您指示网络在每个跃点上使用TLS，并且如果无法拒绝请求，则您宁愿请求失败，也不愿在没有TLS的情况下交付请求。仅将TLS与SIP请求URI一起使用而不是SIPS请求URI意味着“尽力而为”的服务：请求可以但不需要在每个跃点上通过TLS传递。
Another common question is why not have a Proxy-Require and Require option tag forcing the use of TLS instead? The answer is that it would only be functionally equivalent to using SIPS in a Request-URI. SIPS URIs however can be used in many other header fields: in Contact for registration, Contact in dialog-creating requests, Route, Record-Route, Path, From, To, Refer-To, Referred-By, etc. SIPS URIs can also be used in human-usable format (e.g., business cards, user interface). SIPS URIs can even be used in other protocols or document formats that allow for including SIPS URIs (e.g., HTML).
另一个常见的问题是，为什么不使用Proxy Require和Require选项标记来强制使用TLS呢？答案是，它只在功能上等同于在请求URI中使用SIP。但是，SIPS URI可用于许多其他标题字段：联系人注册、联系人对话框创建请求、路由、记录路由、路径、发件人、收件人、参考人、参考人等。SIPS URI也可用于人用格式（例如，名片、用户界面）。SIPS URI甚至可以用于允许包含SIPS URI（例如HTML）的其他协议或文档格式。
This document specifies that SIPS means that the SIP resource designated by the target SIPS URI is to be contacted securely, using TLS on each hop between the UAC and the remote UAS (as opposed to only to the proxy responsible for the target domain of the Request-URI). It is outside of the scope of this document to specify what happens when a SIPS URI identifies a UAS resource that "maps" outside the SIP network, for example, to other networks such as the Public Switched Telephone Network (PSTN).
本文档规定，SIPS意味着要在UAC和远程UAS之间的每个跃点上使用TLS安全地联系由目标SIPS URI指定的SIP资源（而不仅仅是负责请求URI的目标域的代理）。指定当SIPS URI识别出“映射”到SIP网络之外的UAS资源（例如，映射到公共交换电话网络（PSTN））时会发生什么情况超出了本文档的范围。
SIP and SIPS URIs that are identical except for the scheme itself (e.g., sip:alice@example.com and sips:alice@example.com) refer to the same resource. This requirement is implicit in [RFC3261], Section 19.1, which states that "any resource described by a SIP URI can be 'upgraded' to a SIPS URI by just changing the scheme, if it is desired to communicate with that resource securely". This does not mean that the SIPS URI will necessarily be reachable, in particular, if the proxy cannot establish a secure connection to a client or another proxy. This does not suggest either that proxies would arbitrarily "upgrade" SIP URIs to SIPS URIs when forwarding a request (see Section 5.3). Rather, it means that when a resource is addressable with SIP, it will also be addressable with SIPS.
SIP和SIPS URI相同，但方案本身除外（例如，SIP：alice@example.com和sips：alice@example.com)引用相同的资源。该要求隐含在[RFC3261]第19.1节中，该节规定“如果希望与该资源安全通信，则SIP URI描述的任何资源可以通过更改方案“升级”为SIPS URI”。这并不意味着SIPS URI必须是可访问的，特别是当代理无法建立到客户端或另一个代理的安全连接时。这并不意味着代理在转发请求时会任意将SIP URI“升级”为SIPS URI（参见第5.3节）。相反，这意味着当资源可以通过SIP寻址时，它也可以通过SIP寻址。
For example, consider the case of a UA that has registered with a SIPS Contact header field. If a UAC later addresses a request using a SIP Request-URI, the proxy will forward the request addressed to a SIP Request-URI to the UAS, as illustrated by message F13 in Sections 6.3 and in 6.4. The proxy forwards the request to the UA using a SIP Request-URI and not the SIPS Request-URI used in registration. The proxy does this by replacing the SIPS scheme that was used in the
例如，考虑使用SIPS联系人头字段注册的UA的情况。如果UAC随后使用SIP请求URI寻址请求，则代理将向UAS转发寻址到SIP请求URI的请求，如第6.3节和第6.4节中的消息F13所示。代理使用SIP请求URI而不是注册中使用的SIPS请求URI将请求转发给UA。代理通过替换中使用的SIPS方案来实现这一点
registered Contact header field binding with a SIP scheme while leaving the rest of the URI as is, and then by using this new URI as the Request-URI. If the proxy did not do this, and instead used a SIPS Request-URI, then the response (e.g., a 200 to an INVITE) would have to include a SIPS Contact header field. That SIPS Contact header field would then force the other UA to use a SIPS Contact header field in any mid-dialog request, including the ACK (which would not be possible if that UA did not support SIPS).
注册的联系人头字段与SIP方案绑定，同时保持URI的其余部分不变，然后使用此新URI作为请求URI。如果代理没有这样做，而是使用SIPS请求URI，则响应（例如，邀请的200）必须包含SIPS联系人标头字段。然后，该SIPS联系人标头字段将强制其他UA在任何mid对话请求中使用SIPS联系人标头字段，包括ACK（如果该UA不支持SIPS，则不可能）。
This specification mandates that when a proxy is forwarding a request, a resource described by a SIPS Request-URI cannot be "downgraded" to a SIP URI by changing the scheme, or by sending the associated request over a nonsecure link. If a request needs to be rejected because otherwise it would be a "downgrade", the request would be rejected with a 480 (Temporarily Unavailable) response (potentially with a Warning header with warn-code 380 "SIPS Not Allowed"). Similarly, this specification mandates that when a proxy is forwarding a request, a resource described by a SIP Request-URI cannot be "upgraded" to a SIPS URI by changing the scheme (otherwise it would be an "upgrade" only for that hop onwards rather than on all hops, and would therefore mislead the UAS). If a request needs to be rejected because otherwise it would be a misleading "upgrade", the request would be rejected with a 480 (Temporarily Unavailable) response (potentially with a Warning header field with warn-code 381 "SIPS Required"). See Section 5.3 for more details.
本规范规定，当代理转发请求时，不能通过更改方案或通过非安全链路发送相关请求，将SIPS请求URI描述的资源“降级”为SIP URI。如果由于“降级”而需要拒绝请求，则请求将被拒绝，响应为480（暂时不可用）（可能带有警告代码380“不允许SIPS”的警告标头）。类似地，该规范规定，当代理转发请求时，不能通过更改方案将SIP请求URI描述的资源“升级”为SIPS URI（否则，它将仅对该跳进行“升级”，而不是对所有跳进行“升级”，从而误导UAS）。如果请求需要被拒绝，因为否则将是误导性的“升级”，请求将被拒绝，并有480（暂时不可用）响应（可能带有警告代码381“需要SIPS”的警告标头字段）。详见第5.3节。
For example, the sip:bob@example.com and sips:bob@example.com AORs refer to the same user "Bob" in the domain "example.com": the first URI is the SIP version, and the second one is the SIPS version. From the point of view of routing, requests to either sip:bob@example.com or sips:bob@example.com are treated the same way. When Bob registers, it therefore does not really matter if he is using a SIP or a SIPS AOR, since they both refer to the same user. At first glance, Section 19.1.4 of [RFC3261] seems to contradict this idea by stating that a SIP and a SIPS URI are never equivalent. Specifically, it says that they are never equivalent for the purpose of comparing bindings in Contact header field URIs in REGISTER requests. The key point is that this statement applies to the Contact header field bindings in a registration: it is the association of the Contact header field with the AOR that will determine whether or not the user is reachable with a SIPS URI.
例如，sip：bob@example.com和sips：bob@example.comAOR引用域“example.com”中的同一用户“Bob”：第一个URI是SIP版本，第二个是SIPS版本。从路由的角度来看，对sip的请求：bob@example.com或啜饮：bob@example.com他们的待遇是一样的。因此，当Bob注册时，他使用的是SIP还是SIPS AOR并不重要，因为它们都指向同一个用户。乍一看，[RFC3261]的第19.1.4节似乎与这一观点相矛盾，它指出SIP和SIPS URI从来都不是等价的。具体地说，在比较REGISTER请求中的Contact header字段URI中的绑定时，它们从来都不是等价的。关键点在于，此语句适用于注册中的联系人标头字段绑定：联系人标头字段与AOR的关联将决定用户是否可以通过SIPS URI访问。
Consider this example: if Bob (AOR bob@example.com) registers with a SIPS Contact header field (e.g., sips:bob@bobphone.example.com), the registrar and the location service then know that Bob is reachable at sips:bob@bobphone.example.com and at sip:bob@bobphone.example.com.
考虑这个例子：如果鲍伯（AOR）bob@example.com)在SIPS联系人标题字段中注册（例如，SIPS：bob@bobphone.example.com)然后，注册官和定位服务人员知道可以通过sips联系到Bob：bob@bobphone.example.com在sip：bob@bobphone.example.com.
If a request is sent to AOR sips:bob@example.com, Bob's proxy will route it to Bob at Request-URI sips:bob@bobphone.example.com. If a request is sent to AOR sip:bob@example.com, Bob's proxy will route it to Bob at Request-URI sip:bob@bobphone.example.com.
如果向AOR sips发送请求：bob@example.com，Bob的代理将在请求URI sips时将其路由到Bob：bob@bobphone.example.com. 如果向AOR sip发送请求：bob@example.com，Bob的代理将在请求URI sip时将其路由到Bob：bob@bobphone.example.com.
If Bob wants to ensure that every request delivered to him always be transported over TLS, Bob can use [RFC5626] when registering.
如果Bob希望确保发送给他的每个请求始终通过TLS传输，Bob可以在注册时使用[RFC5626]。
However, if Bob had registered with a SIP Contact header field instead of a SIPS Contact header field (e.g., sip:bob@bobphone.example.com), then a request to AOR sips:bob@example.com would not be routed to Bob, since there is no SIPS Contact header field for Bob, and "downgrades" from SIPS to SIP are not allowed.
但是，如果Bob注册了SIP联系人标头字段而不是SIPS联系人标头字段（例如，SIP：bob@bobphone.example.com)，然后向AOR sips发出请求：bob@example.com不会路由到Bob，因为Bob没有SIPS联系人标头字段，并且不允许从SIPS“降级”到SIP。
See Section 6 for illustrative call flows.
请参见第6节，了解说明性调用流。
This section describes all the normative requirements defined by this specification.
本节描述了本规范定义的所有规范性要求。
When presented with a SIPS URI, a UAC MUST NOT change it to a SIP URI. For example, if a directory entry includes a SIPS AOR, the UAC is not expected to send requests to that AOR using a SIP Request-URI. Similarly, if a user reads a business card with a SIPS URI, it is not possible to infer a SIP URI. If a 3XX response includes a SIPS Contact header field, the UAC does not replace it with a SIP Request-URI (e.g., by replacing the SIPS scheme with a SIP scheme) when sending a request as a result of the redirection.
当呈现SIPS URI时，UAC不得将其更改为SIP URI。例如，如果目录条目包括SIPS AOR，则UAC不会使用SIP请求URI向该AOR发送请求。类似地，如果用户读取具有SIPS URI的名片，则无法推断SIP URI。如果3XX响应包含SIPS联系人标头字段，则UAC在作为重定向结果发送请求时不会将其替换为SIP请求URI（例如，通过将SIPS方案替换为SIP方案）。
As mandated by [RFC3261], Section 8.1.1.8, in a request, "if the Request-URI or top Route header field value contains a SIPS URI, the Contact header field MUST contain a SIPS URI as well".
根据[RFC3261]第8.1.1.8节的规定，在请求中，“如果请求URI或顶部路由标头字段值包含SIPS URI，则联系人标头字段也必须包含SIPS URI”。
Upon receiving a 416 response or a 480 (Temporarily Unavailable) response with a Warning header with warn-code 380 "SIPS Not Allowed", a UAC MUST NOT re-attempt the request by automatically replacing the SIPS scheme with a SIP scheme as described in [RFC3261], Section 8.1.3.5, as it would be a security vulnerability. If the UAC does re-attempt the call with a SIP URI, the UAC SHOULD get a confirmation from the user to authorize re-initiating the session with a SIP Request-URI instead of a SIPS Request-URI.
收到带有警告代码380“不允许SIPS”的416响应或480（暂时不可用）响应时，UAC不得通过自动将SIPS方案替换为[RFC3261]第8.1.3.5节所述的SIP方案来重新尝试请求，因为这将是一个安全漏洞。如果UAC确实使用SIP URI重新尝试呼叫，UAC应获得用户的确认，以授权使用SIP请求URI而不是SIPS请求URI重新启动会话。
When the route set is not empty (e.g., when a service route [RFC3608] is returned by the registrar), it is the responsibility of the UAC to use a Route header field consisting of all SIPS URIs when using a SIPS Request-URI. Specifically, if the route set included any SIP URI, the UAC MUST change the SIP URIs to SIPS URIs simply by changing the scheme from "sip" to "sips" before sending the request. This allows for configuring or discovering one service route with all SIP URIs and allowing sending requests to both SIP and SIPS URIs.
当路由集不为空时（例如，当注册器返回服务路由[RFC3608]时），UAC有责任在使用SIPS请求URI时使用包含所有SIPS URI的路由头字段。具体地说，如果路由集包括任何SIP URI，UAC必须在发送请求之前简单地将方案从“SIP”更改为“SIPS”，从而将SIP URI更改为SIPS URI。这允许使用所有SIP URI配置或发现一个服务路由，并允许向SIP和SIPS URI发送请求。
When the UAC is using a SIP Request-URI, if the route set is not empty and the topmost Route header field entry is a SIPS URI with the lr parameter, the UAC MUST send the request over TLS (using a SIP Request-URI). If the route is not empty and the Route header field entry is a SIPS URI without the lr parameter, the UAC MUST send the request over TLS using a SIPS Request-URI corresponding to the topmost entry in the route set.
当UAC使用SIP请求URI时，如果路由集不是空的，并且最上面的路由头字段条目是带有lr参数的SIPS URI，UAC必须通过TLS发送请求（使用SIP请求URI）。如果路由不是空的，并且路由头字段条目是没有lr参数的SIPS URI，UAC必须使用对应于路由集中最顶端条目的SIPS请求URI通过TLS发送请求。
To emphasize what is already defined in [RFC3261], UAs MUST NOT use the "transport=tls" parameter.
为了强调[RFC3261]中已经定义的内容，UAs不得使用“transport=tls”参数。
The UAC registers Contacts header fields to either a SIPS or a SIP AOR.
UAC将联系人标头字段注册到SIPS或SIP AOR。
If a UA wishes to be reachable with a SIPS URI, the UA MUST register with a SIPS Contact header field. Requests addressed to that UA's AOR using either a SIP or SIPS Request-URI will be routed to that UA. This includes UAs that support both SIP and SIPS. This specification does not provide any SIP-based mechanism for a UA to provision its proxy to only forward requests using a SIPS Request-URI. A non-SIP mechanism such as a web interface could be used to provision such a preference. A SIP mechanism for provisioning such a preference is outside the scope of this specification.
如果UA希望通过SIPS URI访问，则UA必须使用SIPS联系人标头字段进行注册。使用SIP或SIPS请求URI向UA的AOR发送的请求将被路由到该UA。这包括同时支持SIP和SIP的UAs。本规范没有为UA提供任何基于SIP的机制，以使其代理仅使用SIPS请求URI转发请求。可以使用非SIP机制（如web接口）来提供这种偏好。用于提供此类首选项的SIP机制不在本规范的范围内。
If a UA does not wish to be reached with a SIPS URI, it MUST register with a SIP Contact header field.
如果UA不希望使用SIPS URI联系，则必须使用SIP联系人标头字段注册。
Because registering with a SIPS Contact header field implies a binding of both a SIPS Contact and a corresponding SIP Contact to the AOR, a UA MUST NOT include both the SIPS and the SIP versions of the same Contact header field in a REGISTER request; the UA MUST only use the SIPS version in this case. Similarly, a UA SHOULD NOT register both a SIP Contact header field and a SIPS Contact header field in separate registrations as the SIP Contact header field would be superfluous. If it does, the second registration replaces the first one (e.g., a UA could register first with a SIP Contact header field, meaning it does not support SIPS, and later register with a SIPS
由于向SIPS联系人报头字段注册意味着SIPS联系人和相应的SIP联系人都绑定到AOR，UA不得在注册请求中同时包括相同联系人报头字段的SIPS和SIP版本；在这种情况下，UA只能使用SIPS版本。类似地，UA不应在单独的注册中同时注册SIP联系人标头字段和SIPS联系人标头字段，因为SIP联系人标头字段是多余的。如果是，则第二次注册将替换第一次注册（例如，UA可以首先注册SIP联系人头字段，这意味着它不支持SIPS，然后注册SIPS）
Contact header field, meaning it now supports SIPS). Similarly, if a UA registers first with a SIPS Contact header field and later registers with a SIP Contact header field, that SIP Contact header field replaces the SIPS Contact header field.
联系人标题字段，这意味着它现在支持SIPS）。类似地，如果UA首先注册SIPS联系人标头字段，然后注册SIP联系人标头字段，则该SIP联系人标头字段将替换SIPS联系人标头字段。
[RFC5626] can be used by a UA if it wants to ensure that no requests are delivered to it without using the TLS connection it used when registering.
如果UA希望确保在不使用注册时使用的TLS连接的情况下不会向其发送任何请求，则可以使用[RFC5626]。
If all the Contact header fields in a REGISTER request are SIPS, the UAC MUST use SIPS AORs in the From and To header fields in the REGISTER request. If at least one of the Contact header fields is not SIPS (e.g., sip, mailto, tel, http, https), the UAC MUST use SIP AORs in the From and To header fields in the REGISTER request.
如果注册请求中的所有联系人标头字段都是SIPS，UAC必须在注册请求中的From和To标头字段中使用SIPS AOR。如果至少有一个联系人标头字段不是SIPS（例如sip、mailto、tel、http、https），UAC必须在注册请求的From和To标头字段中使用sip AOR。
To emphasize what is already defined in [RFC3261], UACs MUST NOT use the "transport=tls" parameter.
为了强调[RFC3261]中已经定义的内容，UACs不得使用“transport=tls”参数。
If the Request-URI in a request that initiates a dialog is a SIP URI, then the UAC needs to be careful about what to use in the Contact header field (in case Record-Route is not used for this hop). If the Contact header field was a SIPS URI, it would mean that the UAS would only accept mid-dialog requests that are sent over secure transport on each hop. Since the Request-URI in this case is a SIP URI, it is quite possible that the UA sending a request to that URI might not be able to send requests to SIPS URIs. If the top Route header field does not contain a SIPS URI, the UAC MUST use a SIP URI in the Contact header field, even if the request is sent over a secure transport (e.g., the first hop could be re-using a TLS connection to the proxy as would be the case with [RFC5626]).
如果发起对话的请求中的请求URI是SIP URI，则UAC需要注意在Contact header字段中使用什么（如果此跃点未使用记录路由）。如果Contact header字段是SIPS URI，则意味着UAS将只接受在每个跃点上通过安全传输发送的mid对话请求。由于本例中的请求URI是SIP URI，因此向该URI发送请求的UA很可能无法向SIPS URI发送请求。如果top Route header字段不包含SIPS URI，UAC必须在Contact header字段中使用SIP URI，即使请求是通过安全传输发送的（例如，第一跳可以像[RFC5626]一样重新使用到代理的TLS连接）。
When a target refresh occurs within a dialog (e.g., re-INVITE request, UPDATE request), the UAC MUST include a Contact header field with a SIPS URI if the original request used a SIPS Request-URI.
当目标刷新在对话框中发生时（例如，重新邀请请求、更新请求），如果原始请求使用SIPS请求URI，UAC必须包含带有SIPS URI的联系人标头字段。
Sessions, dialogs, and transactions can be "derived" from existing ones. A good example of a derived dialog is one that was established as a result of using the REFER method [RFC3515].
会话、对话框和事务可以从现有会话、对话框和事务“派生”。派生对话框的一个很好的示例是使用REFER方法[RFC3515]建立的对话框。
As a general principle, derived dialogs and transactions cannot result in an effective downgrading of SIPS to SIP, without the explicit authorization of the entities involved.
作为一般原则，未经相关实体的明确授权，派生对话框和事务不能有效地将SIP降级为SIP。
For example, when a REFER request is used to perform a call transfer, it results in an existing dialog being terminated and another one being created based on the Refer-To URI. If that initial dialog was established using SIPS, then the UAC MUST NOT establish a new one using SIP, unless there is an explicit authorization given by the recipient of the REFER request. This could be a warning provided to the user. Having such a warning could be useful, for example, for a secure directory service application, to warn a user that a request may be routed to a UA that does not support SIPS.
例如，当REFER请求用于执行呼叫转移时，它会导致终止现有对话框，并基于REFER-REFER URI创建另一个对话框。如果初始对话框是使用SIPS建立的，则UAC不得使用SIP建立新的对话框，除非REFER请求的接收者给予明确授权。这可能是向用户提供的警告。例如，对于安全目录服务应用程序，具有这样的警告可能有用，以警告用户请求可能被路由到不支持SIPS的UA。
A REFER request can also be used for referring to resources that do not result in dialogs being created. In fact, a REFER request can be used to point to resources that are of a different type than the original one (i.e., not SIP or SIPS). Please see [RFC3515], Section 5.2, for security considerations related to this.
引用请求还可用于引用不会导致创建对话框的资源。事实上，REFER请求可用于指向与原始资源类型不同的资源（即，不是SIP或SIPS）。请参阅[RFC3515]，第5.2节，了解与此相关的安全注意事项。
Other examples of derived dialogs and transactions include the use of Third-Party Call Control [RFC3725], the Replaces header field [RFC3891], and the Join header field [RFC3911]. Again, the general principle is that these mechanisms SHOULD NOT result in an effective downgrading of SIPS to SIP, without the proper authorization.
派生对话框和事务的其他示例包括使用第三方呼叫控制[RFC3725]、替换标头字段[RFC3891]和加入标头字段[RFC3911]。同样，一般原则是，未经适当授权，这些机制不应导致SIP有效降级为SIP。
When a Globally Routable User Agent URI (GRUU) [RFC5627] is assigned to an instance ID/AOR pair, both SIP and SIPS GRUUs will be assigned. When a GRUU is obtained through registration, if the Contact header field in the REGISTER request contains a SIP URI, the SIP version of the GRUU is returned. If the Contact header field in the REGISTER request contains a SIPS URI, the SIPS version of the GRUU is returned.
当全局可路由用户代理URI（GRUU）[RFC5627]被分配给实例ID/AOR对时，SIP和SIPS GRUS都将被分配。当通过注册获得GRUU时，如果注册请求中的Contact header字段包含SIP URI，则返回GRUU的SIP版本。如果REGISTER请求中的Contact header字段包含SIPS URI，则返回GRUU的SIPS版本。
If the wrong scheme is received in the GRUU (which would be an error in the registrar), the UAC SHOULD treat it as if the proper scheme was used (i.e., it SHOULD replace the scheme with the proper scheme before using the GRUU).
如果GRUU中接收到错误的方案（这将是注册器中的错误），UAC应将其视为使用了正确的方案（即，在使用GRUU之前，应使用正确的方案替换方案）。
When presented with a SIPS URI, a UAS MUST NOT change it to a SIP URI.
当呈现SIPS URI时，UAS不得将其更改为SIP URI。
As mandated by [RFC3261], Section 12.1.1:
根据[RFC3261]第12.1.1节的规定：
If the request that initiated the dialog contained a SIPS URI in the Request-URI or in the top Record-Route header field value, if there was any, or the Contact header field if there was no Record-Route header field, the Contact header field in the response MUST be a SIPS URI.
如果启动对话框的请求在请求URI或top Record Route header字段值（如果有）或Contact header字段（如果没有Record Route header字段）中包含SIPS URI，则响应中的Contact header字段必须是SIPS URI。
If a UAS does not wish to be reached with a SIPS URI but only with a SIP URI, the UAS MUST respond with a 480 (Temporarily Unavailable) response. The UAS SHOULD include a Warning header with warn-code 380 "SIPS Not Allowed". [RFC3261], Section 8.2.2.1, states that UASs that do not support the SIPS URI scheme at all "SHOULD reject the request with a 416 (Unsupported URI scheme) response".
如果UAS不希望通过SIPS URI而仅通过SIP URI联系，则UAS必须使用480（暂时不可用）响应。UAS应包括一个警告标题，警告代码为380“不允许SIPS”。[RFC3261]第8.2.2.1节指出，根本不支持SIPS URI方案的UAS“应使用416（不支持的URI方案）响应拒绝请求”。
If a UAS does not wish to be contacted with a SIP URI but instead by a SIPS URI, it MUST reject a request to a SIP Request-URI with a 480 (Temporarily Unavailable) response. The UAS SHOULD include a Warning header with warn-code 381 "SIPS Required".
如果UAS不希望与SIP URI联系，而是希望与SIPS URI联系，则它必须使用480（暂时不可用）响应拒绝对SIP请求URI的请求。UAS应包括一个警告标题，警告代码381“需要SIPS”。
It is a matter of local policy for a UAS to accept incoming requests addressed to a URI scheme that does not correspond to what it used for registration. For example, a UA with a policy of "always SIPS" would address the registrar using a SIPS Request-URI over TLS, would register with a SIPS Contact header field, and the UAS would reject requests using the SIP scheme with a 480 (Temporarily Unavailable) response with a Warning header with warn-code 381 "SIPS Required". A UA with a policy of "best-effort SIPS" would address the registrar using a SIPS Request-URI over TLS, would register with a SIPS Contact header field, and the UAS would accept requests addressed to either SIP or SIPS Request-URIs. A UA with a policy of "No SIPS" would address the registrar using a SIP Request-URI, could use TLS or not, would register with a SIP AOR and a SIP Contact header field, and the UAS would accept requests addressed to a SIP Request-URI.
UAS接受发往URI方案的传入请求是本地策略的问题，该URI方案与注册时使用的URI方案不一致。例如，具有“始终SIPS”策略的UA将使用TLS上的SIPS请求URI向注册器寻址，将使用SIPS联系人报头字段注册，并且UAS将使用带有480（暂时不可用）响应的SIP方案拒绝请求，该响应带有警告代码381“需要SIPS”的警告报头。具有“尽力而为SIPS”策略的UA将使用TLS上的SIPS请求URI向注册商发送地址，将使用SIPS联系人标头字段注册，并且UAS将接受发送至SIP或SIPS请求URI的请求。具有“无SIPS”策略的UA将使用SIP请求URI向注册器寻址，可以使用TLS，也可以不使用TLS，将向SIP AOR和SIP联系人头字段注册，并且UAS将接受寻址到SIP请求URI的请求。
If a UAS needs to reject a request because the URIs are used inconsistently (e.g., the Request-URI is a SIPS URI, but the Contact header field is a SIP URI), the UAS MUST reject the request with a 400 (Bad Request) response.
如果UAS需要拒绝请求，因为URI的使用不一致（例如，请求URI是SIPS URI，但Contact header字段是SIP URI），UAS必须以400（错误请求）响应拒绝请求。
When a target refresh occurs within a dialog (e.g., re-INVITE request, UPDATE request), the UAS MUST include a Contact header field with a SIPS URI if the original request used a SIPS Request-URI.
当目标刷新在对话框中发生时（例如，重新邀请请求、更新请求），如果原始请求使用SIPS请求URI，UAS必须包含带有SIPS URI的联系人标头字段。
To emphasize what is already defined in [RFC3261], UASs MUST NOT use the "transport=tls" parameter.
为了强调[RFC3261]中已经定义的内容，UAS不得使用“transport=tls”参数。
The UAC registers Contacts header fields to either a SIPS or a SIP AOR. From a routing perspective, it does not matter which one is used for registration as they identify the same resource. The registrar MUST consider AORs that are identical except for one having the SIP scheme and the other having the SIPS scheme to be equivalent.
UAC将联系人标头字段注册到SIPS或SIP AOR。从路由的角度来看，使用哪一个进行注册并不重要，因为它们标识相同的资源。注册官必须考虑除了一个具有SIP方案和另一个具有SIPS方案相同的AOR之外的相同的AOR。
A registrar MUST accept a binding to a SIPS Contact header field only if all the appropriate URIs are of the SIPS scheme; otherwise, there could be an inadvertent binding of a secure resource (SIPS) to an unsecured one (SIP). This includes the Request-URI and the Contacts and all the Path header fields, but does not include the From and To header fields. If the URIs are not of the proper SIPS scheme, the registrar MUST reject the REGISTER with a 400 (Bad Request).
只有当所有适当的URI都是SIPS方案的URI时，注册员才必须接受与SIPS联系人头字段的绑定；否则，可能会无意中将安全资源（SIPS）绑定到不安全资源（SIP）。这包括请求URI、联系人和所有路径头字段，但不包括From和To头字段。如果URI不符合适当的SIPS方案，注册官必须以400（错误请求）拒绝注册。
A registrar can return a service route [RFC3608] and impose some constraints on whether or not TLS will be mandatory on specific hops. For example, if the topmost entry in the Path header field returned by the registrar is a SIPS URI, the registrar is telling the UAC that TLS is to be used for the first hop, even if the Request-URI is SIP.
注册器可以返回服务路由[RFC3608]，并对TLS是否在特定跳数上是强制性的施加一些约束。例如，如果注册器返回的Path header字段中最顶端的条目是SIPS URI，则注册器告诉UAC TLS将用于第一跳，即使请求URI是SIP。
If a UA registered with a SIPS Contact header field, the registrar returning a service route [RFC3608] MUST return a service route consisting of SIP URIs if the intent of the registrar is to allow both SIP and SIPS to be used in requests sent by that client. If a UA registers with a SIPS Contact header field, the registrar returning a service route MUST return a service route consisting of SIPS URIs if the intent of the registrar is to allow only SIPS URIs to be used in requests sent by that UA.
如果UA使用SIPS联系人报头字段注册，则返回服务路由[RFC3608]的注册器必须返回由SIP URI组成的服务路由，前提是注册器的目的是允许在该客户端发送的请求中同时使用SIP和SIP。如果UA使用SIPS联系人报头字段注册，则如果注册官的意图是仅允许在UA发送的请求中使用SIPS URI，则返回服务路由的注册官必须返回由SIPS URI组成的服务路由。
When a GRUU [RFC5627] is assigned to an instance ID/AOR pair through registration, the registrar MUST assign both a SIP GRUU and a SIPS GRUU. If the Contact header field in the REGISTER request contains a SIP URI, the registrar MUST return the SIP version of the GRUU. If the Contact header field in the REGISTER request contains a SIPS URI, the registrar MUST return the SIPS version of the GRUU.
当通过注册将GRUU[RFC5627]分配给实例ID/AOR对时，注册器必须同时分配SIP GRUU和SIPS GRUU。如果REGISTER请求中的Contact header字段包含SIP URI，则注册器必须返回GRUU的SIP版本。如果REGISTER请求中的Contact header字段包含SIPS URI，则注册器必须返回GRUU的SIPS版本。
Proxies MUST NOT use the last-hop exception of [RFC3261] when forwarding or retargeting a request to the last hop. Specifically, when a proxy receives a request with a SIPS Request-URI, the proxy
将请求转发或重定目标到最后一个跃点时，代理不得使用[RFC3261]的最后一个跃点例外。具体地说，当代理接收到具有SIPS请求URI的请求时，代理
MUST only forward or retarget the request to a SIPS Request-URI. If the target UAS had registered previously using a SIP Contact header field instead of a SIPS Contact header field, the proxy MUST NOT forward the request to the URI indicated in the Contact header field. If the proxy needs to reject the request for that reason, the proxy MUST reject it with a 480 (Temporarily Unavailable) response. In this case, the proxy SHOULD include a Warning header with warn-code 380 "SIPS Not Allowed".
只能将请求转发或重定目标到SIPS请求URI。如果目标UAS以前使用SIP联系人标头字段而不是SIPS联系人标头字段注册，则代理不得将请求转发到联系人标头字段中指示的URI。如果代理服务器因此需要拒绝请求，则代理服务器必须以480（暂时不可用）响应拒绝请求。在这种情况下，代理应包括警告代码为380“不允许SIPS”的警告标头。
Proxies SHOULD transport requests using a SIP URI over TLS when it is possible to set up a TLS connection, or reuse an existing one. [RFC5626], for example, allows for re-using an existing TLS connection. Some proxies could have policies that prohibit sending any request over anything but TLS.
当可以建立TLS连接或重用现有连接时，代理应该通过TLS使用SIPURI传输请求。例如，[RFC5626]允许重新使用现有的TLS连接。某些代理可能具有禁止通过TLS以外的任何方式发送任何请求的策略。
When a proxy receives a request with a SIP Request-URI, the proxy MUST NOT forward the request to a SIPS Request-URI. If the target UAS had registered previously using a SIPS Contact header field, and the proxy decides to forward the request, the proxy MUST replace that SIPS scheme with a SIP scheme while leaving the rest of the URI as is, and use the resulting URI as the Request-URI of the forwarded request. The proxy MUST use TLS to forward the request to the UAS. Some proxies could have a policy of not forwarding at all requests using a non-SIPS Request-URI if the UAS had registered using a SIPS Contact header field. If the proxy elects to reject the request because it has such a policy or because it is not capable of establishing a TLS connection, the proxy MAY reject it with a 480 (Temporarily Unavailable) response with a Warning header with warn-code 381 "SIPS Required".
当代理收到具有SIP请求URI的请求时，代理不得将该请求转发到SIPS请求URI。如果目标UAS先前已使用SIPS联系人标头字段注册，并且代理决定转发请求，则代理必须用SIP方案替换该SIPS方案，同时保持URI的其余部分不变，并将生成的URI用作转发请求的请求URI。代理必须使用TLS将请求转发给UAS。如果UAS已使用SIPS Contact header字段注册，则某些代理可能会有一个策略，即不使用非SIPS请求URI转发所有请求。如果代理选择拒绝请求，因为它有这样的策略，或者因为它不能建立TLS连接，那么代理可能会拒绝请求，并给出480（暂时不可用）响应，该响应带有警告头，警告代码为381“需要SIPS”。
If a proxy needs to reject a request because the URIs are used inconsistently (e.g., the Request-URI is a SIPS URI, but the Contact header field is a SIP URI), the proxy SHOULD use response code 400 (Bad Request).
如果代理需要拒绝请求，因为URI的使用不一致（例如，请求URI是SIPS URI，但联系人标头字段是SIP URI），则代理应使用响应代码400（错误请求）。
It is RECOMMENDED that the proxy use the outbound proxy procedures defined in [RFC5626] for supporting UACs that cannot provide a certificate for establishing a TLS connection (i.e., when server-side authentication is used).
建议代理使用[RFC5626]中定义的出站代理程序来支持无法提供建立TLS连接证书的UAC（即，当使用服务器端身份验证时）。
When a proxy sends a request using a SIPS Request-URI and receives a 3XX response with a SIP Contact header field, or a 416 response, or a 480 (Temporarily Unavailable) response with a Warning header with warn-code 380 "SIPS Not Allowed" response, the proxy MUST NOT recurse on the response. In this case, the proxy SHOULD forward the best response instead of recursing, in order to allow for the UAC to take the appropriate action.
当代理使用SIPS请求URI发送请求并接收带有SIP Contact header字段的3XX响应、416响应或带有警告代码380“SIPS不允许”响应的警告头的480（暂时不可用）响应时，代理不得在响应上重复出现。在这种情况下，代理应该转发最佳响应，而不是递归，以便UAC采取适当的操作。
When a proxy sends a request using a SIP Request-URI and receives a 3XX response with a SIPS Contact header field, or a 480 (Temporarily Unavailable) response with a Warning header with warn-code 381 "SIPS Required", the proxy MUST NOT recurse on the response. In this case, the proxy SHOULD forward the best response instead of recursing, in order to allow for the UAC to take the appropriate action.
当代理使用SIP请求URI发送请求并接收带有SIPS Contact header字段的3XX响应，或收到带有警告代码381“SIPS Required”的警告头的480（暂时不可用）响应时，代理不得在响应上重复出现。在这种情况下，代理应该转发最佳响应，而不是递归，以便UAC采取适当的操作。
To emphasize what is already defined in [RFC3261], proxies MUST NOT use the "transport=tls" parameter.
为了强调[RFC3261]中已经定义的内容，代理不得使用“transport=tls”参数。
Using a redirect server with TLS instead of using a proxy has some limitations that have to be taken into account. Since there is no pre-established connection between the proxy and the UAS (such as with [RFC5626]), it is only appropriate for scenarios where inbound connections are allowed. For example, it could be used in a server-to-server environment (redirect server or proxy server) where TLS mutual authentication is used, and where there are no NAT traversal issues. A redirect server would not be able to redirect to an entity that does not have a certificate. A redirect server might not be usable if there is a NAT between the server and the UAS.
将重定向服务器与TLS一起使用而不是使用代理具有一些必须考虑的限制。由于代理和UAS之间没有预先建立的连接（例如[RFC5626]），因此它仅适用于允许入站连接的场景。例如，它可以用于服务器到服务器环境（重定向服务器或代理服务器），其中使用TLS相互身份验证，并且不存在NAT遍历问题。重定向服务器将无法重定向到没有证书的实体。如果服务器和UAS之间存在NAT，则重定向服务器可能不可用。
When a redirect server receives a request with a SIP Request-URI, the redirect server MAY redirect with a 3XX response to either a SIP or a SIPS Contact header field. If the target UAS had registered previously using a SIPS Contact header field, the redirect server SHOULD return a SIPS Contact header field if it is in an environment where TLS is usable (as described in the previous paragraph). If the target UAS had registered previously using a SIP Contact header field, the redirect server MUST return a SIP Contact header field in a 3XX response if it redirects the request.
当重定向服务器接收到具有SIP请求URI的请求时，重定向服务器可以使用3XX响应重定向到SIP或SIPS联系人头字段。如果目标UAS先前已使用SIPS Contact header字段注册，则重定向服务器应返回SIPS Contact header字段（如果其位于TLS可用的环境中）（如前一段所述）。如果目标UAS先前已使用SIP Contact header字段注册，则如果重定向请求，则重定向服务器必须在3XX响应中返回SIP Contact header字段。
When a redirect server receives a request with a SIPS Request-URI, the redirect server MAY redirect with a 3XX response to a SIP or a SIPS Contact header field. If the target UAS had registered previously using a SIPS Contact header field, the redirect server SHOULD return a SIPS Contact header field if it is in an environment where TLS is usable. If the target UAS had registered previously using a SIP Contact header field, the redirect server MUST return a SIP Contact header field in a 3XX response if it chooses to redirect; otherwise, the UAS MAY reject the request with a 480 (Temporarily Unavailable) response with a Warning header with warn-code 380 "SIPS Not Allowed". If a redirect server redirects to a UAS that it has no knowledge of (e.g., an AOR in a different domain), the Contact header field could be of any scheme.
当重定向服务器接收到具有SIPS请求URI的请求时，重定向服务器可以使用3XX响应重定向到SIP或SIPS联系人头字段。如果目标UAS先前已使用SIPS Contact header字段注册，则重定向服务器应返回SIPS Contact header字段（如果其位于TLS可用的环境中）。如果目标UAS先前已使用SIP Contact header字段注册，则如果选择重定向，重定向服务器必须在3XX响应中返回SIP Contact header字段；否则，UAS可能会以480（暂时不可用）响应拒绝请求，该响应带有警告头，警告代码380“不允许SIPS”。如果重定向服务器重定向到它不知道的UAS（例如，不同域中的AOR），则联系人标头字段可以是任何方案。
If a redirect server needs to reject a request because the URIs are used inconsistently (e.g., the Request-URI is a SIPS URI, but the Contact header field is a SIP URI), the redirect server SHOULD use response code 400 (Bad Request).
如果重定向服务器需要拒绝请求，因为URI的使用不一致（例如，请求URI是SIPS URI，但联系人标头字段是SIP URI），则重定向服务器应使用响应代码400（错误请求）。
To emphasize what is already defined in [RFC3261], redirect servers MUST NOT use the "transport=tls" parameter.
为了强调[RFC3261]中已经定义的内容，重定向服务器不得使用“transport=tls”参数。
The following diagram illustrates the topology used for the examples in this section:
下图说明了本节示例中使用的拓扑：
example.com . example.net
.
|-------------| . |------------|
| Registrar/ |__________| Proxy A |
| Auth. Proxy | . | (proxya) |
| (pb) | . |------------|
|-------------| . |
| . |
| . |
|-----------| . |
| Edge | . |
| Proxy B | . |
| (eb) | . |
|-----------| . |
/ | . |
/ | . |
/ | . |
______ | . |
| | _____ . _____
|______| O / \ O . O / \ O
/_______/ /___\ . /___\
.
bob@bobpc bob@bobphone . alice
example.com . example.net
.
|-------------| . |------------|
| Registrar/ |__________| Proxy A |
| Auth. Proxy | . | (proxya) |
| (pb) | . |------------|
|-------------| . |
| . |
| . |
|-----------| . |
| Edge | . |
| Proxy B | . |
| (eb) | . |
|-----------| . |
/ | . |
/ | . |
/ | . |
______ | . |
| | _____ . _____
|______| O / \ O . O / \ O
/_______/ /___\ . /___\
.
bob@bobpc bob@bobphone . alice
Topology
拓扑学
In the following examples, Bob has two clients; one is a SIP PC client running on his computer, and the other one is a SIP phone. The PC client does not support SIPS, and consequently only registers with a SIP Contact header field. The SIP phone however does support SIPS and TLS, and consequently registers with a SIPS Contact header field. Both of Bob's devices are going through Edge Proxy B, and consequently, they include a Route header field indicating
在以下示例中，Bob有两个客户机；一个是在他的计算机上运行的SIP PC客户端，另一个是SIP电话。PC客户端不支持SIP，因此只在SIP联系人头字段中注册。然而，SIP电话确实支持SIPS和TLS，因此在SIPS联系人报头字段中注册。Bob的两个设备都通过边缘代理B，因此，它们包含一个路由头字段，指示
eb.example.com. Edge Proxy B removes the Route header field corresponding to itself, and adds itself in a Path header field. The registration process call flow is illustrated in Section 6.1.
eb.example.com。边缘代理B删除与自身对应的路由头字段，并将自身添加到路径头字段中。注册过程调用流程如第6.1节所示。
After registration, there are two Contact bindings associated with Bob's AOR of bob@example.com: sips:bob@bobphone.example.com and sip:bob@bobpc.example.com.
注册后，有两个联系人绑定与Bob的AOR关联bob@example.com：sips:bob@bobphone.example.com及sip:bob@bobpc.example.com.
Alice then calls Bob through her own Proxy A. Proxy A locates Bob's domain example.com. In this example, that domain is owned by Bob's Registrar/Authoritative Proxy B. Proxy A removes the Route header field corresponding to itself, and inserts itself in the Record-Route and forwards the request to Registrar/Authoritative Proxy B.
然后Alice通过自己的代理A给Bob打电话。代理A定位Bob的域名example.com。在此示例中，该域归Bob的注册/权威代理B所有。代理A删除与其对应的路由头字段，并将其自身插入记录路由，并将请求转发给注册/权威代理B。
The following subsections illustrate registration and three examples. In the first example (Section 6.2), Alice calls Bob's SIPS AOR. In the second example (Section 6.3), Alice calls Bob's SIP AOR using TCP transport. In the third example (Section 6.4), Alice calls Bob's SIP AOR using TLS transport.
以下小节说明了注册和三个示例。在第一个示例（第6.2节）中，Alice调用Bob的SIPS AOR。在第二个示例（第6.3节）中，Alice使用TCP传输调用Bob的SIP AOR。在第三个示例（第6.4节）中，Alice使用TLS传输调用Bob的SIP AOR。
This flow illustrates the registration process by which Bob's device registers. His PC client (Bob@bobpc) registers with a SIP scheme, and his SIP phone (Bob@phone) registers with a SIPS scheme.
此流程说明了Bob的设备注册的注册过程。他的电脑客户端(Bob@bobpc)使用SIP方案注册，并使用他的SIP电话(Bob@phone)向SIPS方案注册。
(eb) (pb)
Edge Registrar/
Bob@bobpc Proxy B Auth. Proxy B
| | |
| REGISTER F1 | |
|------------------>| REGISTER F2 |
| |-------------->|
| | 200 F3 |
| 200 F4 |<--------------|
|<------------------| |
| | |
| Bob@bobphone | |
| | | |
| |REGISTER F5 | |
| |----------->| REGISTER F6 |
| | |-------------->|
| | | 200 F7 |
| | 200 F8 |<--------------|
| |<-----------| |
| | | |
(eb) (pb)
Edge Registrar/
Bob@bobpc Proxy B Auth. Proxy B
| | |
| REGISTER F1 | |
|------------------>| REGISTER F2 |
| |-------------->|
| | 200 F3 |
| 200 F4 |<--------------|
|<------------------| |
| | |
| Bob@bobphone | |
| | | |
| |REGISTER F5 | |
| |----------->| REGISTER F6 |
| | |-------------->|
| | | 200 F7 |
| | 200 F8 |<--------------|
| |<-----------| |
| | | |
Bob Registers His Contacts
鲍勃登记他的联系人
Message details
消息详细信息
F1 REGISTER Bob's PC Client -> Edge Proxy B
F1注册Bob的PC客户端->边缘代理B
REGISTER sip:pb.example.com SIP/2.0
Via: SIP/2.0/TCP bobpc.example.com:5060;branch=z9hG4bKnashds
Max-Forwards: 70
To: Bob <sip:bob@example.com>
From: Bob <sip:bob@example.com>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Supported: path, outbound
Route: <sip:eb.example.com;lr>
Contact: <sip:bob@bobpc.example.com>
;+sip.instance="<urn:uuid:0C67446E-F1A1-11D9-94D3-000A95A0E128>"
;reg-id=1
Content-Length: 0
REGISTER sip:pb.example.com SIP/2.0
Via: SIP/2.0/TCP bobpc.example.com:5060;branch=z9hG4bKnashds
Max-Forwards: 70
To: Bob <sip:bob@example.com>
From: Bob <sip:bob@example.com>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Supported: path, outbound
Route: <sip:eb.example.com;lr>
Contact: <sip:bob@bobpc.example.com>
;+sip.instance="<urn:uuid:0C67446E-F1A1-11D9-94D3-000A95A0E128>"
;reg-id=1
Content-Length: 0
F2 REGISTER Edge Proxy B -> Registrar/Authoritative Proxy B
F2 REGISTER Edge Proxy B -> Registrar/Authoritative Proxy B
REGISTER sip:pb.example.com SIP/2.0
Via: SIP/2.0/TCP eb.example.com:5060;branch=z9hG4bK87asdks7
Via: SIP/2.0/TCP bobpc.example.com:5060;branch=z9hG4bKnashds
Max-Forwards: 69
To: Bob <sip:bob@example.com>
From: Bob <sip:bob@example.com>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Supported: path, outbound
Path: <sip:laksdyjanseg237+fsdf+uy623hytIJ8@eb.example.com;lr;ob>
Contact: <sip:bob@bobpc.example.com>
;+sip.instance="<urn:uuid:0C67446E-F1A1-11D9-94D3-000A95A0E128>"
;reg-id=1
Content-Length: 0
REGISTER sip:pb.example.com SIP/2.0
Via: SIP/2.0/TCP eb.example.com:5060;branch=z9hG4bK87asdks7
Via: SIP/2.0/TCP bobpc.example.com:5060;branch=z9hG4bKnashds
Max-Forwards: 69
To: Bob <sip:bob@example.com>
From: Bob <sip:bob@example.com>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Supported: path, outbound
Path: <sip:laksdyjanseg237+fsdf+uy623hytIJ8@eb.example.com;lr;ob>
Contact: <sip:bob@bobpc.example.com>
;+sip.instance="<urn:uuid:0C67446E-F1A1-11D9-94D3-000A95A0E128>"
;reg-id=1
Content-Length: 0
F3 200 (REGISTER) Registrar/Authoritative Proxy B -> Edge Proxy B
F3 200 (REGISTER) Registrar/Authoritative Proxy B -> Edge Proxy B
SIP/2.0 200 OK
Via: SIP/2.0/TCP eb.example.com:5060;branch=z9hG4bK87asdks7
Via: SIP/2.0/TCP bobpc.example.com:5060;branch=z9hG4bKnashds
To: Bob <sip:bob@example.com>;tag=2493K59K9
From: Bob <sip:bob@example.com>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Require: outbound
Supported: path, outbound
Path: <sip:laksdyjanseg237+fsdf+uy623hytIJ8@eb.example.com;lr;ob>
Contact: <sip:bob@bobphone.example.com>
;+sip.instance="<urn:uuid:0C67446E-F1A1-11D9-94D3-000A95A0E128>"
;reg-id=1
;expires=3600
Date: Mon, 12 Jun 2006 16:43:12 GMT
Content-Length: 0
SIP/2.0 200 OK
Via: SIP/2.0/TCP eb.example.com:5060;branch=z9hG4bK87asdks7
Via: SIP/2.0/TCP bobpc.example.com:5060;branch=z9hG4bKnashds
To: Bob <sip:bob@example.com>;tag=2493K59K9
From: Bob <sip:bob@example.com>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Require: outbound
Supported: path, outbound
Path: <sip:laksdyjanseg237+fsdf+uy623hytIJ8@eb.example.com;lr;ob>
Contact: <sip:bob@bobphone.example.com>
;+sip.instance="<urn:uuid:0C67446E-F1A1-11D9-94D3-000A95A0E128>"
;reg-id=1
;expires=3600
Date: Mon, 12 Jun 2006 16:43:12 GMT
Content-Length: 0
F4 200 (REGISTER) Edge Proxy B -> Bob's PC Client
F4 200（寄存器）边缘代理B->Bob的PC客户端
SIP/2.0 200 OK
Via: SIP/2.0/TCP bobpc.example.com:5060;branch=z9hG4bKnashds
To: Bob <sip:bob@example.com>;tag=2493K59K9
From: Bob <sip:bob@example.com>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Require: outbound
Supported: path, outbound
Path: <sip:laksdyjanseg237+fsdf+uy623hytIJ8@eb.example.com;lr;ob>
Contact: <sip:bob@bobphone.example.com>
;+sip.instance="<urn:uuid:0C67446E-F1A1-11D9-94D3-000A95A0E128>"
;reg-id=1
;expires=3600
Date: Thu, 09 Aug 2007 16:43:12 GMT
Content-Length: 0
SIP/2.0 200 OK
Via: SIP/2.0/TCP bobpc.example.com:5060;branch=z9hG4bKnashds
To: Bob <sip:bob@example.com>;tag=2493K59K9
From: Bob <sip:bob@example.com>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Require: outbound
Supported: path, outbound
Path: <sip:laksdyjanseg237+fsdf+uy623hytIJ8@eb.example.com;lr;ob>
Contact: <sip:bob@bobphone.example.com>
;+sip.instance="<urn:uuid:0C67446E-F1A1-11D9-94D3-000A95A0E128>"
;reg-id=1
;expires=3600
Date: Thu, 09 Aug 2007 16:43:12 GMT
Content-Length: 0
F5 REGISTER Bob's Phone -> Edge Proxy B
F5注册Bob的手机->边缘代理B
REGISTER sips:pb.example.com SIP/2.0
Via: SIP/2.0/TLS bobphone.example.com:5061;branch=z9hG4bK9555
Max-Forwards: 70
To: Bob <sips:bob@example.com>
From: Bob <sips:bob@example.com>;tag=90210
Call-ID: faif9a@qwefnwdclk
CSeq: 12 REGISTER
Supported: path, outbound
Route: <sips:eb.example.com;lr>
Contact: <sips:bob@bobphone.example.com>
;+sip.instance="<urn:uuid:6F85D4E3-E8AA-46AA-B768-BF39D5912143>"
;reg-id=1
Content-Length: 0
REGISTER sips:pb.example.com SIP/2.0
Via: SIP/2.0/TLS bobphone.example.com:5061;branch=z9hG4bK9555
Max-Forwards: 70
To: Bob <sips:bob@example.com>
From: Bob <sips:bob@example.com>;tag=90210
Call-ID: faif9a@qwefnwdclk
CSeq: 12 REGISTER
Supported: path, outbound
Route: <sips:eb.example.com;lr>
Contact: <sips:bob@bobphone.example.com>
;+sip.instance="<urn:uuid:6F85D4E3-E8AA-46AA-B768-BF39D5912143>"
;reg-id=1
Content-Length: 0
F6 REGISTER Edge Proxy B -> Registrar/Authoritative Proxy B
F6 REGISTER Edge Proxy B -> Registrar/Authoritative Proxy B
REGISTER sips:pb.example.com SIP/2.0
Via: SIP/2.0/TLS eb.example.com:5061;branch=z9hG4bK876354
Via: SIP/2.0/TLS bobphone.example.com:5061;branch=z9hG4bK9555
Max-Forwards: 69
To: Bob <sips:bob@example.com>
From: Bob <sips:bob@example.com>;tag=90210
Call-ID: faif9a@qwefnwdclk
CSeq: 12 REGISTER
Supported: path, outbound
Path: <sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>
Contact: <sips:bob@bobphone.example.com>
;+sip.instance="<urn:uuid:6F85D4E3-E8AA-46AA-B768-BF39D5912143>"
;reg-id=1
Content-Length: 0
REGISTER sips:pb.example.com SIP/2.0
Via: SIP/2.0/TLS eb.example.com:5061;branch=z9hG4bK876354
Via: SIP/2.0/TLS bobphone.example.com:5061;branch=z9hG4bK9555
Max-Forwards: 69
To: Bob <sips:bob@example.com>
From: Bob <sips:bob@example.com>;tag=90210
Call-ID: faif9a@qwefnwdclk
CSeq: 12 REGISTER
Supported: path, outbound
Path: <sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>
Contact: <sips:bob@bobphone.example.com>
;+sip.instance="<urn:uuid:6F85D4E3-E8AA-46AA-B768-BF39D5912143>"
;reg-id=1
Content-Length: 0
F7 200 (REGISTER) Registrar/Authoritative Proxy B -> Edge Proxy B
F7 200 (REGISTER) Registrar/Authoritative Proxy B -> Edge Proxy B
SIP/2.0 200 OK
Via: SIP/2.0/TLS eb.example.com:5061;branch=z9hG4bK876354
Via: SIP/2.0/TLS bobphone.example.com:5061;branch=z9hG4bK9555
To: Bob <sips:bob@example.com>;tag=5150
From: Bob <sips:bob@example.com>;tag=90210
Call-ID: faif9a@qwefnwdclk
CSeq: 12 REGISTER
Require: outbound
Supported: path, outbound
Path: <sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>
Contact: <sips:bob@bobphone.example.com>
;+sip.instance="<urn:uuid:6F85D4E3-E8AA-46AA-B768-BF39D5912143>"
;reg-id=1
;expires=3600
Date: Thu, 09 Aug 2007 16:43:50 GMT
Content-Length: 0
SIP/2.0 200 OK
Via: SIP/2.0/TLS eb.example.com:5061;branch=z9hG4bK876354
Via: SIP/2.0/TLS bobphone.example.com:5061;branch=z9hG4bK9555
To: Bob <sips:bob@example.com>;tag=5150
From: Bob <sips:bob@example.com>;tag=90210
Call-ID: faif9a@qwefnwdclk
CSeq: 12 REGISTER
Require: outbound
Supported: path, outbound
Path: <sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>
Contact: <sips:bob@bobphone.example.com>
;+sip.instance="<urn:uuid:6F85D4E3-E8AA-46AA-B768-BF39D5912143>"
;reg-id=1
;expires=3600
Date: Thu, 09 Aug 2007 16:43:50 GMT
Content-Length: 0
F8 200 (REGISTER) Edge Proxy B -> Bob's Phone
F8 200（寄存器）边缘代理B->鲍勃的手机
SIP/2.0 200 OK
Via: SIP/2.0/TLS bobphone.example.com:5061;branch=z9hG4bK9555
To: Bob <sips:bob@example.com>;tag=5150
From: Bob <sips:bob@example.com>;tag=90210
Call-ID: faif9a@qwefnwdclk
CSeq: 12 REGISTER
Require: outbound
Supported: path, outbound
Path: <sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>
Contact: <sips:bob@bobphone.example.com>
;+sip.instance="<urn:uuid:6F85D4E3-E8AA-46AA-B768-BF39D5912143>"
;reg-id=1
;expires=3600
Date: Thu, 09 Aug 2007 16:43:50 GMT
Content-Length: 0
SIP/2.0 200 OK
Via: SIP/2.0/TLS bobphone.example.com:5061;branch=z9hG4bK9555
To: Bob <sips:bob@example.com>;tag=5150
From: Bob <sips:bob@example.com>;tag=90210
Call-ID: faif9a@qwefnwdclk
CSeq: 12 REGISTER
Require: outbound
Supported: path, outbound
Path: <sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>
Contact: <sips:bob@bobphone.example.com>
;+sip.instance="<urn:uuid:6F85D4E3-E8AA-46AA-B768-BF39D5912143>"
;reg-id=1
;expires=3600
Date: Thu, 09 Aug 2007 16:43:50 GMT
Content-Length: 0
Bob's registration has already occurred as per Section 6.1.
Bob的注册已按照第6.1节进行。
In this first example, Alice calls Bob's SIPS AOR (sips:bob@example.com). Registrar/Authoritative Proxy B consults the binding in the registration database, and finds the two Contact header field bindings. Alice had addressed Bob with a SIPS Request-URI (sips:bob@example.com), so Registrar/Authoritative Proxy B determines that the call needs to be routed only to bobphone (which registered using a SIPS Contact header field), and therefore the request is only sent to sips:bob@bobphone.example.com, through Edge Proxy B. Both Registrar/Authoritative Proxy B and Edge Proxy B insert themselves in the Record-Route. Bob answers at sips:bob@bobphone.example.com.
在第一个示例中，Alice调用Bob的SIPS AOR（SIPS:bob@example.com). 注册商/权威代理B查阅注册数据库中的绑定，并查找两个联系人头字段绑定。Alice用SIPS请求URI（SIPS:bob@example.com)，因此注册商/权威代理B确定呼叫只需要路由到bobphone（使用SIPS联系人标头字段注册），因此请求只发送到SIPS：bob@bobphone.example.com,通过边缘代理B。注册者/权威代理B和边缘代理B都将自己插入记录路由。Bob在sips上回答：bob@bobphone.example.com.
(eb) (pb)
Edge Registrar/
Bob@bobpc Proxy B Auth. Proxy B Proxy A Alice
| | | | |
| | | | INVITE F9 |
| Bob@bobphone | | INVITE F11 |<-----------|
| | | INVITE F13 |<-----------| 100 F10 |
| | INVITE F15 |<-----------| 100 F12 |----------->|
| |<-----------| 100 F14 |----------->| |
| | 180 F16 |----------->| | |
| |----------->| 180 F17 | | |
| | 200 F20 |----------->| 180 F18 | |
| |----------->| 200 F21 |----------->| 180 F19 |
| | |----------->| 200 F22 |----------->|
| | | |----------->| 200 F23 |
| | | | |----------->|
| | | | | ACK F24 |
| | | | ACK F25 |<-----------|
| | | ACK F26 |<-----------| |
| | ACK F27 |<-----------| | |
| |<-----------| | | |
| | | | | |
(eb) (pb)
Edge Registrar/
Bob@bobpc Proxy B Auth. Proxy B Proxy A Alice
| | | | |
| | | | INVITE F9 |
| Bob@bobphone | | INVITE F11 |<-----------|
| | | INVITE F13 |<-----------| 100 F10 |
| | INVITE F15 |<-----------| 100 F12 |----------->|
| |<-----------| 100 F14 |----------->| |
| | 180 F16 |----------->| | |
| |----------->| 180 F17 | | |
| | 200 F20 |----------->| 180 F18 | |
| |----------->| 200 F21 |----------->| 180 F19 |
| | |----------->| 200 F22 |----------->|
| | | |----------->| 200 F23 |
| | | | |----------->|
| | | | | ACK F24 |
| | | | ACK F25 |<-----------|
| | | ACK F26 |<-----------| |
| | ACK F27 |<-----------| | |
| |<-----------| | | |
| | | | | |
Alice Calls Bob's SIPS AOR
爱丽丝叫鲍勃小口喝AOR
Message details
消息详细信息
F9 INVITE Alice -> Proxy A
F9邀请Alice->代理A
INVITE sips:bob@example.com SIP/2.0
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
Max-Forwards: 70
To: Bob <sips:bob@example.com>
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Route: <sips:proxya.example.net;lr>
Contact: <sips:alice@alice-1.example.net>
Content-Type: application/sdp
Content-Length: {as per SDP}
{SDP not shown}
INVITE sips:bob@example.com SIP/2.0
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
Max-Forwards: 70
To: Bob <sips:bob@example.com>
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Route: <sips:proxya.example.net;lr>
Contact: <sips:alice@alice-1.example.net>
Content-Type: application/sdp
Content-Length: {as per SDP}
{SDP not shown}
F10 100 (INVITE) Proxy A -> Alice
F10 100（邀请）代理A->Alice
SIP/2.0 100 Trying
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
To: Bob <sips:bob@example.com>
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Content-Length: 0
SIP/2.0 100 Trying
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
To: Bob <sips:bob@example.com>
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Content-Length: 0
F11 INVITE Proxy A -> Registrar/Authoritative Proxy B
F11 INVITE Proxy A -> Registrar/Authoritative Proxy B
INVITE sips:bob@example.com SIP/2.0
Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
Max-Forwards: 69
To: Bob <sips:bob@example.com>
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route: <sips:proxya.example.net;lr>
Contact: <sips:alice@alice-1.example.net>
Content-Type: application/sdp
Content-Length: {as per SDP}
{SDP not shown}
INVITE sips:bob@example.com SIP/2.0
Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
Max-Forwards: 69
To: Bob <sips:bob@example.com>
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route: <sips:proxya.example.net;lr>
Contact: <sips:alice@alice-1.example.net>
Content-Type: application/sdp
Content-Length: {as per SDP}
{SDP not shown}
F12 100 (INVITE) Registrar/Authoritative Proxy B -> Proxy A
F12 100 (INVITE) Registrar/Authoritative Proxy B -> Proxy A
SIP/2.0 100 Trying
Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
To: Bob <sips:bob@example.com>
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Content-Length: 0
SIP/2.0 100 Trying
Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
To: Bob <sips:bob@example.com>
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Content-Length: 0
F13 INVITE Registrar/Authoritative Proxy B -> Edge Proxy B
F13 INVITE Registrar/Authoritative Proxy B -> Edge Proxy B
INVITE sips:bob@bobphone.example.com SIP/2.0
Via: SIP/2.0/TLS pb.example.com:5061;branch=z9hG4bKbalouba
Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
Max-Forwards: 68
To: Bob <sips:bob@example.com>
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Route:
<sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@edge.example.com;lr;ob>
Record-Route: <sips:pb.example.com;lr>, <sips:proxya.example.net;lr>
Contact: <sips:alice@alice-1.example.net>
Content-Type: application/sdp
Content-Length: {as per SDP}
{SDP not shown}
INVITE sips:bob@bobphone.example.com SIP/2.0
Via: SIP/2.0/TLS pb.example.com:5061;branch=z9hG4bKbalouba
Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
Max-Forwards: 68
To: Bob <sips:bob@example.com>
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Route:
<sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@edge.example.com;lr;ob>
Record-Route: <sips:pb.example.com;lr>, <sips:proxya.example.net;lr>
Contact: <sips:alice@alice-1.example.net>
Content-Type: application/sdp
Content-Length: {as per SDP}
{SDP not shown}
F14 100 (INVITE) Edge Proxy B -> Registrar/Authoritative Proxy B
F14 100 (INVITE) Edge Proxy B -> Registrar/Authoritative Proxy B
SIP/2.0 100 Trying
Via: SIP/2.0/TLS pb.example.com:5061;branch=z9hG4bKbalouba
Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
To: Bob <sips:bob@example.com>
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Content-Length: 0
SIP/2.0 100 Trying
Via: SIP/2.0/TLS pb.example.com:5061;branch=z9hG4bKbalouba
Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
To: Bob <sips:bob@example.com>
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Content-Length: 0
F15 INVITE Edge Proxy B -> Bob's phone
F15邀请边缘代理B->鲍勃的手机
INVITE sips:bob@bobphone.example.com SIP/2.0
Via: SIP/2.0/TLS eb.example.com:5061;branch=z9hG4bKbiba
Via: SIP/2.0/TLS pb.example.com:5061;branch=z9hG4bKbalouba
Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
Max-Forwards: 67
To: Bob <sips:bob@example.com>
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
<sips:pb.example.com;lr>, <sips:proxya.example.net;lr>
Contact: <sips:alice@alice-1.example.net>
Content-Type: application/sdp
Content-Length: {as per SDP}
{SDP not shown}
INVITE sips:bob@bobphone.example.com SIP/2.0
Via: SIP/2.0/TLS eb.example.com:5061;branch=z9hG4bKbiba
Via: SIP/2.0/TLS pb.example.com:5061;branch=z9hG4bKbalouba
Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
Max-Forwards: 67
To: Bob <sips:bob@example.com>
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
<sips:pb.example.com;lr>, <sips:proxya.example.net;lr>
Contact: <sips:alice@alice-1.example.net>
Content-Type: application/sdp
Content-Length: {as per SDP}
{SDP not shown}
F16 180 (INVITE) Bob's Phone -> Edge Proxy B
F16 180（邀请）Bob的手机->边缘代理B
SIP/2.0 180 Ringing
Via: SIP/2.0/TLS eb.example.com:5061;branch=z9hG4bKbiba
Via: SIP/2.0/TLS pb.example.com:5061;branch=z9hG4bKbalouba
Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
To: Bob <sips:bob@example.com>;tag=5551212
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
<sips:pb.example.com;lr>, <sips:proxya.example.net;lr>
Contact: <sips:bob@bobphone.example.com>
Content-Length: 0
SIP/2.0 180 Ringing
Via: SIP/2.0/TLS eb.example.com:5061;branch=z9hG4bKbiba
Via: SIP/2.0/TLS pb.example.com:5061;branch=z9hG4bKbalouba
Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
To: Bob <sips:bob@example.com>;tag=5551212
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
<sips:pb.example.com;lr>, <sips:proxya.example.net;lr>
Contact: <sips:bob@bobphone.example.com>
Content-Length: 0
F17 180 (INVITE) Edge Proxy B -> Registrar/Authoritative Proxy B
F17 180 (INVITE) Edge Proxy B -> Registrar/Authoritative Proxy B
SIP/2.0 180 Ringing
Via: SIP/2.0/TLS pb.example.com:5061;branch=z9hG4bKbalouba
Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
To: Bob <sips:bob@example.com>;tag=5551212
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
<sips:pb.example.com;lr>, <sips:proxya.example.net;lr>
Contact: <sips:bob@bobphone.example.com>
Content-Length: 0
SIP/2.0 180 Ringing
Via: SIP/2.0/TLS pb.example.com:5061;branch=z9hG4bKbalouba
Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
To: Bob <sips:bob@example.com>;tag=5551212
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
<sips:pb.example.com;lr>, <sips:proxya.example.net;lr>
Contact: <sips:bob@bobphone.example.com>
Content-Length: 0
F18 180 Registrar/Authoritative Proxy B -> Proxy A
F18 180 Registrar/Authoritative Proxy B -> Proxy A
SIP/2.0 180 Ringing
Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
To: Bob <sips:bob@example.com>;tag=5551212
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
<sips:pb.example.com;lr>, <sips:proxya.example.net;lr>
Contact: <sips:bob@bobphone.example.com>
Content-Length: 0
SIP/2.0 180 Ringing
Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
To: Bob <sips:bob@example.com>;tag=5551212
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
<sips:pb.example.com;lr>, <sips:proxya.example.net;lr>
Contact: <sips:bob@bobphone.example.com>
Content-Length: 0
F19 180 (INVITE) Proxy A -> Alice
F19 180（邀请）代理A->Alice
SIP/2.0 180 Ringing
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
To: Bob <sips:bob@example.com>;tag=5551212
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
<sips:pb.example.com;lr>, <sips:proxya.example.net;lr>
Contact: <sips:bob@bobphone.example.com>
Content-Length: 0
SIP/2.0 180 Ringing
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
To: Bob <sips:bob@example.com>;tag=5551212
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
<sips:pb.example.com;lr>, <sips:proxya.example.net;lr>
Contact: <sips:bob@bobphone.example.com>
Content-Length: 0
F20 200 (INVITE) Bob's Phone -> Edge Proxy B
F20 200（邀请）鲍勃的手机->边缘代理B
SIP/2.0 200 OK
Via: SIP/2.0/TLS eb.example.com:5061;branch=z9hG4bKbiba
Via: SIP/2.0/TLS pb.example.com:5061;branch=z9hG4bKbalouba
Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
To: Bob <sips:bob@example.com>;tag=5551212
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
<sips:pb.example.com;lr>, <sips:proxya.example.net;lr>
Contact: <sips:bob@bobphone.example.com>
Content-Length: 0
SIP/2.0 200 OK
Via: SIP/2.0/TLS eb.example.com:5061;branch=z9hG4bKbiba
Via: SIP/2.0/TLS pb.example.com:5061;branch=z9hG4bKbalouba
Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
To: Bob <sips:bob@example.com>;tag=5551212
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
<sips:pb.example.com;lr>, <sips:proxya.example.net;lr>
Contact: <sips:bob@bobphone.example.com>
Content-Length: 0
F21 200 (INVITE) Edge Proxy B -> Registrar/Authoritative Proxy B
F21 200 (INVITE) Edge Proxy B -> Registrar/Authoritative Proxy B
SIP/2.0 200 OK
Via: SIP/2.0/TLS pb.example.com:5061;branch=z9hG4bKbalouba
Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
To: Bob <sips:bob@example.com>;tag=5551212
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
<sips:pb.example.com;lr>, <sips:proxya.example.net;lr>
Contact: <sips:bob@bobphone.example.com>
Content-Length: 0
SIP/2.0 200 OK
Via: SIP/2.0/TLS pb.example.com:5061;branch=z9hG4bKbalouba
Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
To: Bob <sips:bob@example.com>;tag=5551212
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
<sips:pb.example.com;lr>, <sips:proxya.example.net;lr>
Contact: <sips:bob@bobphone.example.com>
Content-Length: 0
F22 200 Registrar/Authoritative Proxy B -> Proxy A
F22 200 Registrar/Authoritative Proxy B -> Proxy A
SIP/2.0 200 OK
Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
To: Bob <sips:bob@example.com>;tag=5551212
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
<sips:pb.example.com;lr>, <sips:proxya.example.net;lr>
Contact: <sips:bob@bobphone.example.com>
Content-Length: 0
SIP/2.0 200 OK
Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
To: Bob <sips:bob@example.com>;tag=5551212
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
<sips:pb.example.com;lr>, <sips:proxya.example.net;lr>
Contact: <sips:bob@bobphone.example.com>
Content-Length: 0
F23 200 (INVITE) Proxy A -> Alice
F23 200（邀请）代理A->Alice
SIP/2.0 200 OK
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
To: Bob <sips:bob@example.com>;tag=5551212
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
<sips:pb.example.com;lr>, <sips:proxya.example.net;lr>
Contact: <sips:bob@bobphone.example.com>
Content-Length: 0
SIP/2.0 200 OK
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
To: Bob <sips:bob@example.com>;tag=5551212
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
<sips:pb.example.com;lr>, <sips:proxya.example.net;lr>
Contact: <sips:bob@bobphone.example.com>
Content-Length: 0
F24 ACK Alice -> Proxy A
确认->代理A
ACK sips:bob@bobphone.example.com SIP/2.0
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKksdjf
Max-Forwards: 70
To: Bob <sips:bob@example.com>;tag=5551212
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 ACK
Route: <sips:proxya.example.net;lr>, <sips:pb.example.com;lr>,
<sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@pb.example.com;lr;ob>
Content-Length: 0
ACK sips:bob@bobphone.example.com SIP/2.0
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKksdjf
Max-Forwards: 70
To: Bob <sips:bob@example.com>;tag=5551212
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 ACK
Route: <sips:proxya.example.net;lr>, <sips:pb.example.com;lr>,
<sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@pb.example.com;lr;ob>
Content-Length: 0
F25 ACK Proxy A -> Registrar/Authoritative Proxy B
F25 ACK Proxy A -> Registrar/Authoritative Proxy B
ACK sips:bob@bobphone.example.com SIP/2.0
Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKplo7hy
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKksdjf
Max-Forwards: 69
To: Bob <sips:bob@example.com>;tag=5551212
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 ACK
Route: <sips:pb.example.com;lr>,
<sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@pb.example.com;lr;ob>
Content-Length: 0
ACK sips:bob@bobphone.example.com SIP/2.0
Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKplo7hy
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKksdjf
Max-Forwards: 69
To: Bob <sips:bob@example.com>;tag=5551212
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 ACK
Route: <sips:pb.example.com;lr>,
<sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@pb.example.com;lr;ob>
Content-Length: 0
F26 ACK Registrar/Authoritative Proxy B -> Edge Proxy B
F26 ACK Registrar/Authoritative Proxy B -> Edge Proxy B
ACK sips:bob@bobphone.example.com SIP/2.0
Via: SIP/2.0/TLS pb.example.com:5061;branch=z9hG4bK8msdu2
Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKplo7hy
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKksdjf
Max-Forwards: 69
To: Bob <sips:bob@example.com>;tag=5551212
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 ACK
Route: <sips:pb.example.com;lr>,
<sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@pb.example.com;lr;ob>
Content-Length: 0
ACK sips:bob@bobphone.example.com SIP/2.0
Via: SIP/2.0/TLS pb.example.com:5061;branch=z9hG4bK8msdu2
Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKplo7hy
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKksdjf
Max-Forwards: 69
To: Bob <sips:bob@example.com>;tag=5551212
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 ACK
Route: <sips:pb.example.com;lr>,
<sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@pb.example.com;lr;ob>
Content-Length: 0
F27 ACK Proxy B -> Bob's Phone
确认代理B->鲍勃的电话
ACK sips:bob@bobphone.example.com SIP/2.0
Via: SIP/2.0/TLS eb.example.com:5061;branch=z9hG4bKkmfdgk
Via: SIP/2.0/TLS pb.example.com:5061;branch=z9hG4bK8msdu2
Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKplo7hy
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKksdjf
Max-Forwards: 68
To: Bob <sips:bob@example.com>;tag=5551212
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 ACK
Content-Length: 0
ACK sips:bob@bobphone.example.com SIP/2.0
Via: SIP/2.0/TLS eb.example.com:5061;branch=z9hG4bKkmfdgk
Via: SIP/2.0/TLS pb.example.com:5061;branch=z9hG4bK8msdu2
Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKplo7hy
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKksdjf
Max-Forwards: 68
To: Bob <sips:bob@example.com>;tag=5551212
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 ACK
Content-Length: 0
Bob's registration has already occurred as per Section 6.1.
Bob的注册已按照第6.1节进行。
In the second example, Alice calls Bob's SIP AOR instead (sip:bob@example.com), and she uses TCP as a transport. Registrar/ Authoritative Proxy B consults the binding in the registration database, and finds the two Contact header field bindings. Alice had addressed Bob with a SIP Request-URI (sip:bob@example.com), so Registrar/Authoritative Proxy B determines that the call needs to be routed both to bobpc (which registered with a SIP Contact header field) and bobphone (which registered with a SIPS Contact header field), and therefore the request is forked to sip:bob@bobpc.example.com and sip:bob@bobphone.example.com, through Edge Proxy B. Note that Registrar/Authoritative Proxy B preserved the SIP scheme of the Request-URI instead of replacing it with the SIPS scheme of the Contact header field that was used for registration. Both Registrar/Authoritative Proxy B and Edge Proxy B insert themselves in the Record-Route. Bob's phone's policy is to accept calls to SIP and SIPS (i.e., "best effort"), so both his PC client and his SIP phone ring simultaneously. Bob answers on his SIP phone, and the forked call leg to the PC client is canceled.
在第二个示例中，Alice调用Bob的SIP AOR（SIP:bob@example.com)，她使用TCP作为传输。注册商/权威代理B查阅注册数据库中的绑定，并查找两个联系人头字段绑定。Alice用SIP请求URI（SIP:bob@example.com)，因此注册商/权威代理B确定呼叫需要路由到bobpc（注册到SIP联系人报头字段）和bobphone（注册到SIPS联系人报头字段），因此，请求被转移到sip：bob@bobpc.example.com及sip:bob@bobphone.example.com，通过边缘代理B。请注意，注册商/权威代理B保留了请求URI的SIP方案，而不是将其替换为用于注册的联系人标头字段的SIPS方案。注册商/权威代理B和边缘代理B都将自己插入记录路由。Bob的手机政策是接受SIP和SIPS的呼叫（即“尽力而为”），因此他的PC客户端和SIP手机同时响起。Bob用他的SIP电话接听电话，与PC客户端的分路呼叫被取消。
(eb) (pb)
Edge Registrar/
Bob@bobpc Proxy B Auth. Proxy B Proxy A Alice
| | | | |
| | | | INVITE F9 |
| | | INVITE F11 |<-----------|
| | INVITE F13'|<-----------| 100 F10 |
| INVITE F15' |<-----------| 100 F12 |----------->|
|<------------------| 100 F14' |----------->| |
| 180 F16' |----------->| | |
|------------------>| 180 F17' | | |
| |----------->| 180 F18' | |
| Bob@bobphone | |----------->| 180 F19' |
| | | INVITE F13 | |----------->|
| | INVITE F15 |<-----------| | |
| |<-----------| 100 F14 | | |
| | 180 F16 |----------->| | |
| |----------->| 180 F17 | | |
| | 200 F20 |----------->| 180 F18 | |
| |----------->| 200 F21 |----------->| 180 F19 |
| | |----------->| 200 F22 |----------->|
| | | |----------->| 200 F23 |
| | | | |----------->|
| | | | | ACK F24 |
| | | | ACK F25 |<-----------|
| | | ACK F26 |<-----------| |
| | ACK F27 |<-----------| | |
| |<-----------| | | |
| | CANCEL F26'| | |
| CANCEL F27' |<-----------| | |
|<------------------| | | |
| 200 F28' | | | |
|------------------>| 200 F29' | | |
| 487 F30' |----------->| | |
|------------------>| 487 F31' | | |
| |----------->| | |
(eb) (pb)
Edge Registrar/
Bob@bobpc Proxy B Auth. Proxy B Proxy A Alice
| | | | |
| | | | INVITE F9 |
| | | INVITE F11 |<-----------|
| | INVITE F13'|<-----------| 100 F10 |
| INVITE F15' |<-----------| 100 F12 |----------->|
|<------------------| 100 F14' |----------->| |
| 180 F16' |----------->| | |
|------------------>| 180 F17' | | |
| |----------->| 180 F18' | |
| Bob@bobphone | |----------->| 180 F19' |
| | | INVITE F13 | |----------->|
| | INVITE F15 |<-----------| | |
| |<-----------| 100 F14 | | |
| | 180 F16 |----------->| | |
| |----------->| 180 F17 | | |
| | 200 F20 |----------->| 180 F18 | |
| |----------->| 200 F21 |----------->| 180 F19 |
| | |----------->| 200 F22 |----------->|
| | | |----------->| 200 F23 |
| | | | |----------->|
| | | | | ACK F24 |
| | | | ACK F25 |<-----------|
| | | ACK F26 |<-----------| |
| | ACK F27 |<-----------| | |
| |<-----------| | | |
| | CANCEL F26'| | |
| CANCEL F27' |<-----------| | |
|<------------------| | | |
| 200 F28' | | | |
|------------------>| 200 F29' | | |
| 487 F30' |----------->| | |
|------------------>| 487 F31' | | |
| |----------->| | |
Alice Calls Bob's SIP AOR
爱丽丝把鲍勃的SIP叫作AOR
Message details
消息详细信息
F9 INVITE Alice -> Proxy A
F9邀请Alice->代理A
INVITE sip:bob@example.com SIP/2.0
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
Max-Forwards: 70
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Route: <sip:proxya.example.net;lr>
Contact: <sip:alice@alice-1.example.net>
Content-Type: application/sdp
Content-Length: {as per SDP}
{SDP not shown}
INVITE sip:bob@example.com SIP/2.0
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
Max-Forwards: 70
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Route: <sip:proxya.example.net;lr>
Contact: <sip:alice@alice-1.example.net>
Content-Type: application/sdp
Content-Length: {as per SDP}
{SDP not shown}
F10 100 (INVITE) Proxy A -> Alice
F10 100（邀请）代理A->Alice
SIP/2.0 100 Trying
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Content-Length: 0
SIP/2.0 100 Trying
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Content-Length: 0
F11 INVITE Proxy A -> Registrar/Authoritative Proxy B
F11 INVITE Proxy A -> Registrar/Authoritative Proxy B
INVITE sip:bob@example.com SIP/2.0
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
Max-Forwards: 69
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route: <sip:proxya.example.net;lr>
Contact: <sip:alice@alice-1.example.net>
Content-Type: application/sdp
Content-Length: {as per SDP}
{SDP not shown}
INVITE sip:bob@example.com SIP/2.0
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
Max-Forwards: 69
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route: <sip:proxya.example.net;lr>
Contact: <sip:alice@alice-1.example.net>
Content-Type: application/sdp
Content-Length: {as per SDP}
{SDP not shown}
F12 100 (INVITE) Registrar/Authoritative Proxy B -> Proxy A
F12 100 (INVITE) Registrar/Authoritative Proxy B -> Proxy A
SIP/2.0 100 Trying
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Content-Length: 0
SIP/2.0 100 Trying
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Content-Length: 0
F13' INVITE Registrar/Authoritative Proxy B -> Edge Proxy B
F13' INVITE Registrar/Authoritative Proxy B -> Edge Proxy B
INVITE sip:bob@bobpc.example.com SIP/2.0
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
Max-Forwards: 68
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Route: <sip:laksdyjanseg237+fsdf+uy623hytIJ8@eb.example.com;lr;ob>
Record-Route: <sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
Contact: <sip:alice@alice-1.example.net>
Content-Type: application/sdp
Content-Length: {as per SDP}
{SDP not shown}
INVITE sip:bob@bobpc.example.com SIP/2.0
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
Max-Forwards: 68
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Route: <sip:laksdyjanseg237+fsdf+uy623hytIJ8@eb.example.com;lr;ob>
Record-Route: <sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
Contact: <sip:alice@alice-1.example.net>
Content-Type: application/sdp
Content-Length: {as per SDP}
{SDP not shown}
F14' 100 (INVITE) Edge Proxy B -> Registrar/Authoritative Proxy B
F14' 100 (INVITE) Edge Proxy B -> Registrar/Authoritative Proxy B
SIP/2.0 100 Trying
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Content-Length: 0
SIP/2.0 100 Trying
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Content-Length: 0
F15' INVITE Edge Proxy B -> Bob's PC Client
F15'邀请边缘代理B->Bob的PC客户端
INVITE sip:bob@bobpc.example.com SIP/2.0
Via: SIP/2.0/TCP eb.example.com:5060;branch=z9hG4bKbiba
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
Max-Forwards: 67
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sip:laksdyjanseg237+fsdf+uy623hytIJ8@eb.example.com;lr;ob>,
<sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
Contact: <sip:alice@alice-1.example.net>
Content-Type: application/sdp
Content-Length: {as per SDP}
{SDP not shown}
INVITE sip:bob@bobpc.example.com SIP/2.0
Via: SIP/2.0/TCP eb.example.com:5060;branch=z9hG4bKbiba
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
Max-Forwards: 67
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sip:laksdyjanseg237+fsdf+uy623hytIJ8@eb.example.com;lr;ob>,
<sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
Contact: <sip:alice@alice-1.example.net>
Content-Type: application/sdp
Content-Length: {as per SDP}
{SDP not shown}
F16' 180 (INVITE) Bob's PC Client -> Edge Proxy B
F16'180（邀请）Bob的PC客户端->边缘代理B
SIP/2.0 180 Ringing
Via: SIP/2.0/TCP eb.example.com:5060;branch=z9hG4bKbiba
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>;tag=963258
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sip:laksdyjanseg237+fsdf+uy623hytIJ8@eb.example.com;lr;ob>,
<sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
Contact: <sip:bob@bobpc.example.com>
Content-Length: 0
SIP/2.0 180 Ringing
Via: SIP/2.0/TCP eb.example.com:5060;branch=z9hG4bKbiba
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>;tag=963258
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sip:laksdyjanseg237+fsdf+uy623hytIJ8@eb.example.com;lr;ob>,
<sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
Contact: <sip:bob@bobpc.example.com>
Content-Length: 0
F17' 180 (INVITE) Edge Proxy B -> Registrar/Authoritative Proxy B
F17' 180 (INVITE) Edge Proxy B -> Registrar/Authoritative Proxy B
SIP/2.0 180 Ringing
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>;tag=963258
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sip:laksdyjanseg237+fsdf+uy623hytIJ8@eb.example.com;lr;ob>,
<sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
Contact: <sip:bob@bobpc.example.com>
Content-Length: 0
SIP/2.0 180 Ringing
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>;tag=963258
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sip:laksdyjanseg237+fsdf+uy623hytIJ8@eb.example.com;lr;ob>,
<sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
Contact: <sip:bob@bobpc.example.com>
Content-Length: 0
F18' 180 (INVITE) Registrar/Authoritative Proxy B -> Proxy A
F18' 180 (INVITE) Registrar/Authoritative Proxy B -> Proxy A
SIP/2.0 180 Ringing
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>;tag=963258
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sip:laksdyjanseg237+fsdf+uy623hytIJ8@eb.example.com;lr;ob>,
<sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
Contact: <sip:bob@bobpc.example.com>
Content-Length: 0
SIP/2.0 180 Ringing
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>;tag=963258
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sip:laksdyjanseg237+fsdf+uy623hytIJ8@eb.example.com;lr;ob>,
<sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
Contact: <sip:bob@bobpc.example.com>
Content-Length: 0
F19' 180 (INVITE) Proxy A -> Alice
F19'180（邀请）代理A->Alice
SIP/2.0 180 Ringing
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>;tag=963258
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sip:laksdyjanseg237+fsdf+uy623hytIJ8@eb.example.com;lr;ob>,
<sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
Contact: <sip:bob@bobpc.example.com>
Content-Length: 0
SIP/2.0 180 Ringing
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>;tag=963258
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sip:laksdyjanseg237+fsdf+uy623hytIJ8@eb.example.com;lr;ob>,
<sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
Contact: <sip:bob@bobpc.example.com>
Content-Length: 0
F13 INVITE Registrar/Authoritative Proxy B -> Edge Proxy B
F13 INVITE Registrar/Authoritative Proxy B -> Edge Proxy B
INVITE sip:bob@bobphone.example.com SIP/2.0
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.1
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
Max-Forwards: 68
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Route: <sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>
Record-Route: <sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
Contact: <sip:alice@alice-1.example.net>
Content-Type: application/sdp
Content-Length: {as per SDP}
{SDP not shown}
INVITE sip:bob@bobphone.example.com SIP/2.0
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.1
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
Max-Forwards: 68
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Route: <sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>
Record-Route: <sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
Contact: <sip:alice@alice-1.example.net>
Content-Type: application/sdp
Content-Length: {as per SDP}
{SDP not shown}
F14 100 (INVITE) Edge Proxy B -> Registrar/Authoritative Proxy B
F14 100 (INVITE) Edge Proxy B -> Registrar/Authoritative Proxy B
SIP/2.0 100 Trying
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.1
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Content-Length: 0
SIP/2.0 100 Trying
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.1
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Content-Length: 0
F15 INVITE Edge Proxy B -> Bob's Phone
F15邀请边缘代理B->鲍勃的手机
INVITE sip:bob@bobphone.example.com SIP/2.0
Via: SIP/2.0/TLS eb.example.com:5061;branch=z9hG4bKtroubaba
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.1
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
Max-Forwards: 68
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
<sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
Contact: <sip:alice@alice-1.example.net>
Content-Type: application/sdp
Content-Length: {as per SDP}
{SDP not shown}
INVITE sip:bob@bobphone.example.com SIP/2.0
Via: SIP/2.0/TLS eb.example.com:5061;branch=z9hG4bKtroubaba
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.1
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
Max-Forwards: 68
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
<sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
Contact: <sip:alice@alice-1.example.net>
Content-Type: application/sdp
Content-Length: {as per SDP}
{SDP not shown}
F16 180 (INVITE) Bob's Phone -> Edge Proxy B
F16 180（邀请）Bob的手机->边缘代理B
SIP/2.0 180 Ringing
Via: SIP/2.0/TLS eb.example.com:5061;branch=z9hG4bKtroubaba
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.1
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>;tag=5551212
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
<sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
Contact: <sip:bob@bobphone.example.com>
Content-Length: 0
SIP/2.0 180 Ringing
Via: SIP/2.0/TLS eb.example.com:5061;branch=z9hG4bKtroubaba
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.1
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>;tag=5551212
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
<sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
Contact: <sip:bob@bobphone.example.com>
Content-Length: 0
F17 180 (INVITE) Edge Proxy B -> Registrar/Authoritative Proxy B
F17 180 (INVITE) Edge Proxy B -> Registrar/Authoritative Proxy B
SIP/2.0 180 Ringing
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.1
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>;tag=5551212
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
<sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
Contact: <sip:bob@bobphone.example.com>
Content-Length: 0
SIP/2.0 180 Ringing
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.1
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>;tag=5551212
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
<sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
Contact: <sip:bob@bobphone.example.com>
Content-Length: 0
F18 180 (INVITE) Registrar/Authoritative Proxy B -> Proxy A
F18 180 (INVITE) Registrar/Authoritative Proxy B -> Proxy A
SIP/2.0 180 Ringing
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>;tag=5551212
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
<sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
Contact: <sip:bob@bobphone.example.com>
Content-Length: 0
SIP/2.0 180 Ringing
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>;tag=5551212
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
<sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
Contact: <sip:bob@bobphone.example.com>
Content-Length: 0
F19 180 (INVITE) Proxy A -> Alice
F19 180（邀请）代理A->Alice
SIP/2.0 180 Ringing
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>;tag=5551212
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
<sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
Contact: <sip:bob@bobphone.example.com>
Content-Length: 0
SIP/2.0 180 Ringing
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>;tag=5551212
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
<sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
Contact: <sip:bob@bobphone.example.com>
Content-Length: 0
F20 200 (INVITE) Bob's Phone -> Edge Proxy B
F20 200（邀请）鲍勃的手机->边缘代理B
SIP/2.0 200 OK
Via: SIP/2.0/TLS eb.example.com:5061;branch=z9hG4bKtroubaba
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.1
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>;tag=5551212
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
<sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
Contact: <sip:bob@bobphone.example.com>
Content-Length: 0
SIP/2.0 200 OK
Via: SIP/2.0/TLS eb.example.com:5061;branch=z9hG4bKtroubaba
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.1
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>;tag=5551212
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
<sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
Contact: <sip:bob@bobphone.example.com>
Content-Length: 0
F21 200 (INVITE) Edge Proxy B -> Registrar/Authoritative Proxy B
F21 200 (INVITE) Edge Proxy B -> Registrar/Authoritative Proxy B
SIP/2.0 200 OK
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.1
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>;tag=5551212
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
<sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
Contact: <sip:bob@bobphone.example.com>
Content-Length: 0
SIP/2.0 200 OK
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.1
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>;tag=5551212
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
<sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
Contact: <sip:bob@bobphone.example.com>
Content-Length: 0
F22 200 (INVITE) Registrar/Authoritative Proxy B -> Proxy A
F22 200 (INVITE) Registrar/Authoritative Proxy B -> Proxy A
SIP/2.0 200 OK
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>;tag=5551212
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
<sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
Contact: <sip:bob@bobphone.example.com>
Content-Length: 0
SIP/2.0 200 OK
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>;tag=5551212
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
<sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
Contact: <sip:bob@bobphone.example.com>
Content-Length: 0
F23 200 (INVITE) Proxy A -> Alice
F23 200（邀请）代理A->Alice
SIP/2.0 200 OK
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>;tag=5551212
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
<sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
Contact: <sip:bob@bobphone.example.com>
Content-Length: 0
SIP/2.0 200 OK
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>;tag=5551212
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
<sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
Contact: <sip:bob@bobphone.example.com>
Content-Length: 0
F24 ACK Alice -> Proxy A
确认->代理A
ACK sip:bob@bobphone.example.com SIP/2.0
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
Max-Forwards: 70
To: Bob <sip:bob@example.com>;tag=5551212
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 ACK
Route: <sip:proxya.example.net;lr>, <sip:pb.example.com;lr>,
<sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@edge.example.com;lr;ob>
Content-Length: 0
ACK sip:bob@bobphone.example.com SIP/2.0
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
Max-Forwards: 70
To: Bob <sip:bob@example.com>;tag=5551212
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 ACK
Route: <sip:proxya.example.net;lr>, <sip:pb.example.com;lr>,
<sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@edge.example.com;lr;ob>
Content-Length: 0
F25 ACK Proxy A -> Registrar/Authoritative Proxy B
F25 ACK Proxy A -> Registrar/Authoritative Proxy B
ACK sip:bob@bobphone.example.com SIP/2.0
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
Max-Forwards: 69
To: Bob <sip:bob@example.com>;tag=5551212
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 ACK
Route: <sip:pb.example.com;lr>,
<sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>
Content-Length: 0
ACK sip:bob@bobphone.example.com SIP/2.0
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
Max-Forwards: 69
To: Bob <sip:bob@example.com>;tag=5551212
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 ACK
Route: <sip:pb.example.com;lr>,
<sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>
Content-Length: 0
F26 ACK Registrar/Authoritative Proxy B -> Edge Proxy B
F26 ACK Registrar/Authoritative Proxy B -> Edge Proxy B
ACK sip:bob@bobphone.example.com SIP/2.0
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.1
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
Max-Forwards: 69
To: Bob <sip:bob@example.com>;tag=5551212
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 ACK
Route: <sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>
Content-Length: 0
ACK sip:bob@bobphone.example.com SIP/2.0
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.1
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
Max-Forwards: 69
To: Bob <sip:bob@example.com>;tag=5551212
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 ACK
Route: <sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>
Content-Length: 0
F27 ACK Proxy B -> Bob's Phone
确认代理B->鲍勃的电话
ACK sip:bob@bobphone.example.com SIP/2.0
Via: SIP/2.0/TLS eb.example.com:5061;branch=z9hG4bKtroubaba
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.1
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
Max-Forwards: 68
To: Bob <sip:bob@example.com>;tag=5551212
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 ACK
Content-Length: 0
ACK sip:bob@bobphone.example.com SIP/2.0
Via: SIP/2.0/TLS eb.example.com:5061;branch=z9hG4bKtroubaba
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.1
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
Max-Forwards: 68
To: Bob <sip:bob@example.com>;tag=5551212
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 ACK
Content-Length: 0
F26' CANCEL Registrar/Authoritative Proxy B -> Edge Proxy B
F26' CANCEL Registrar/Authoritative Proxy B -> Edge Proxy B
CANCEL sip:bob@bobpc.example.com SIP/2.0
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2
Max-Forwards: 70
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 CANCEL
Route: <sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>
Content-Length: 0
CANCEL sip:bob@bobpc.example.com SIP/2.0
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2
Max-Forwards: 70
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 CANCEL
Route: <sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>
Content-Length: 0
F27' CANCEL Edge Proxy B -> Bob's PC Client
F27'取消边缘代理B->Bob的PC客户端
CANCEL sip:bob@bobpc.example.com SIP/2.0
Via: SIP/2.0/TCP eb.example.com:5060;branch=z9hG4bKtroubaba
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2
Max-Forwards: 69
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 CANCEL
Content-Length: 0
CANCEL sip:bob@bobpc.example.com SIP/2.0
Via: SIP/2.0/TCP eb.example.com:5060;branch=z9hG4bKtroubaba
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2
Max-Forwards: 69
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 CANCEL
Content-Length: 0
F28' 200 (CANCEL) Bob's PC Client -> Edge Proxy B
F28'200（取消）Bob的PC客户端->边缘代理B
SIP/2.0 200 OK
Via: SIP/2.0/TCP eb.example.com:5060;branch=z9hG4bKtroubaba
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 CANCEL
Content-Length: 0
SIP/2.0 200 OK
Via: SIP/2.0/TCP eb.example.com:5060;branch=z9hG4bKtroubaba
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 CANCEL
Content-Length: 0
F29' 200 (CANCEL) Edge Proxy B -> Registrar/Authoritative Proxy B
F29' 200 (CANCEL) Edge Proxy B -> Registrar/Authoritative Proxy B
SIP/2.0 200 OK
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 CANCEL
Content-Length: 0
SIP/2.0 200 OK
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 CANCEL
Content-Length: 0
F30' 487 (INVITE) Bob's PC Client -> Edge Proxy B
F30'487（邀请）Bob的PC客户端->边缘代理B
SIP/2.0 487 Request Terminated
Via: SIP/2.0/TCP eb.example.com:5060;branch=z9hG4bKtroubaba
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Content-Length: 0
SIP/2.0 487 Request Terminated
Via: SIP/2.0/TCP eb.example.com:5060;branch=z9hG4bKtroubaba
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Content-Length: 0
F31' 487 (INVITE) Edge Proxy B -> Registrar/Authoritative Proxy B
F31' 487 (INVITE) Edge Proxy B -> Registrar/Authoritative Proxy B
SIP/2.0 487 Request Terminated
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Content-Length: 0
SIP/2.0 487 Request Terminated
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Content-Length: 0
Bob's registration has already occurred as per Section 6.1.
Bob的注册已按照第6.1节进行。
The third example is identical to the second one, except that Alice uses TLS as the transport for her connection to her proxy. Such an arrangement would be common if Alice's UA supported TLS and wanted to use a single connection to the proxy (as would be the case when using [RFC5626]). In the example below, Proxy A is also using TLS as a transport to communicate with Outbound Proxy B, but it is not necessarily the case.
第三个示例与第二个示例相同，只是Alice使用TLS作为连接到其代理的传输。如果Alice的UA支持TLS并希望使用到代理的单一连接（使用[RFC5626]时就是这种情况），则这种安排将很常见。在下面的示例中，代理A也使用TLS作为与出站代理B通信的传输，但情况并非如此。
When using a SIP URI in the Request-URI but TLS as a transport for sending the request, the Via field indicates TLS. The Route header field (if present) typically would use a SIP URI (but it could also be a SIPS URI). The Contact header fields and To and From, however would also normally indicate a SIP URI.
当在请求URI中使用SIP URI而不是TLS作为发送请求的传输时，Via字段指示TLS。路由头字段（如果存在）通常会使用SIPURI（但也可以是SIPS URI）。然而，Contact头字段和To和From通常也表示SIPURI。
The call flow would be exactly as per the second example (Section 6.3). The only difference would be that all the Via header fields would use TLS Via parameters. The URIs would remain SIP URIs and not SIPS URIs.
调用流与第二个示例（第6.3节）完全相同。唯一的区别是所有Via头字段都将使用TLS Via参数。URI将仍然是SIP URI，而不是SIPS URI。
SIP [RFC3261] itself introduces some complications with using SIPS, for example, when Record-Route is not used. When a SIPS URI is used in a Contact header field in a dialog-initiating request and Record-Route is not used, that SIPS URI might not be usable by the other end. If the other end does not support SIPS and/or TLS, it will not be able to use it. The last-hop exception is an example of when this can occur. In this case, using Record-Route so that the requests are sent through proxies can help in making it work. Another example is that even in a case where the Contact header field is a SIPS URI, no Record-Route is used, and the far end supports SIPS and TLS, it might still not be possible for the far end to establish a TLS connection with the SIP originating end if the certificate cannot be validated by the far end. This could typically be the case if the originating end was using server-side authentication as described below, or if the originating end is not using a certificate that can be validated.
SIP[RFC3261]本身在使用SIPS时引入了一些复杂因素，例如，当不使用记录路由时。当SIPS URI在发起请求的对话框中的联系人标头字段中使用且未使用记录路由时，另一端可能无法使用该SIPS URI。如果另一端不支持SIPS和/或TLS，则将无法使用它。最后一个跃点异常就是发生这种情况的一个例子。在这种情况下，使用记录路由以便通过代理发送请求有助于使其正常工作。另一个例子是，即使在联系人报头字段是SIPS URI的情况下，没有使用记录路由，并且远端支持SIPS和TLS，如果远端不能验证证书，远端也可能无法与SIP发起端建立TLS连接。如果始发端使用如下所述的服务器端身份验证，或者始发端未使用可验证的证书，则通常会出现这种情况。
TLS itself has a significant impact on how SIPS can be used. Server-side authentication (where the server side provides its certificate but the client side does not) is typically used between a SIP end-user device acting as the TLS client side (e.g., a phone or a personal computer) and its SIP server (proxy or registrar) acting as the TLS server side. TLS mutual authentication (where both the client side and the server side provide their respective certificates) is typically used between SIP servers (proxies, registrars), or statically configured devices such as PSTN gateways or media servers. In the mutual authentication model, for two entities to be able to establish a TLS connection, it is required that both sides be able to validate each other's certificates, either by static configuration or by being able to recurse to a valid root certificate. With server-side authentication, only the client side is capable of validating the server side's certificate, as the client side does not provide a certificate. The consequences of all this are that whenever a SIPS URI is used to establish a TLS connection, it is expected to be possible for the entity establishing the connection (the client) to validate the certificate from the server side. For server-side authentication, [RFC5626] is the recommended approach. For mutual authentication, one needs to ensure that the architecture of the network is such that connections are made between entities that have access to each other's certificates. Record-Route [RFC3261] and Path [RFC3327] are very useful in ensuring that previously established TLS connections can be reused. Other mechanisms might also be used in certain circumstances: for example, using root certificates that are widely recognized allows for more easily created TLS connections.
TLS本身对SIPS的使用方式有重大影响。服务器端认证（其中服务器端提供其证书，但客户端不提供）通常在充当TLS客户端（例如，电话或个人计算机）的SIP最终用户设备与其充当TLS服务器端的SIP服务器（代理或注册器）之间使用。TLS相互认证（客户端和服务器端都提供各自的证书）通常在SIP服务器（代理、注册器）或静态配置的设备（如PSTN网关或媒体服务器）之间使用。在相互认证模型中，为了使两个实体能够建立TLS连接，要求双方能够通过静态配置或通过能够递归到有效的根证书来验证彼此的证书。使用服务器端身份验证，只有客户端能够验证服务器端的证书，因为客户端不提供证书。所有这些的结果是，无论何时使用SIPS URI建立TLS连接，建立连接的实体（客户端）都可以从服务器端验证证书。对于服务器端身份验证，建议使用[RFC5626]。对于相互认证，需要确保网络的体系结构能够在能够访问彼此证书的实体之间建立连接。记录路由[RFC3261]和路径[RFC3327]对于确保以前建立的TLS连接可以重用非常有用。在某些情况下也可以使用其他机制：例如，使用广泛认可的根证书可以更容易地创建TLS连接。
Most of this document can be considered to be security considerations since it applies to the usage of the SIPS URI.
由于本文档适用于SIPS URI的使用，因此可以将其视为安全考虑事项。
The "last-hop exception" of [RFC3261] introduced significant potential vulnerabilities in SIP, and it has therefore been deprecated by this specification.
[RFC3261]的“最后一跳异常”在SIP中引入了严重的潜在漏洞，因此本规范不推荐使用该漏洞。
Section 26.4.4 of [RFC3261] describes the security considerations for the SIPS URI scheme. These security considerations also applies here, as modified by Appendix A.
[RFC3261]第26.4.4节描述了SIPS URI方案的安全注意事项。如附录A所修改，这些安全注意事项也适用于此处。
This specification registers two new warning codes, namely, 380 "SIPS Not Allowed" and 381 "SIPS Required". The warning codes are defined as follows, and have been included in the Warning Codes (warn-codes) sub-registry of the SIP Parameters registry available from http://www.iana.org.
本规范登记了两个新的警告代码，即380“不允许SIPS”和381“需要SIPS”。警告代码定义如下，已包含在SIP参数注册表的警告代码（警告代码）子注册表中，可从http://www.iana.org.
380 SIPS Not Allowed: The UAS or proxy cannot process the request because the SIPS scheme is not allowed (e.g., because there are currently no registered SIPS contacts).
380不允许SIP：UAS或代理无法处理请求，因为不允许SIPS方案（例如，因为目前没有注册的SIPS联系人）。
381 SIPS Required: The UAS or proxy cannot process the request because the SIPS scheme is required.
381需要SIPS：UAS或代理无法处理该请求，因为需要SIPS方案。
Reference: RFC 5630
参考：RFC5630
The note in the Warning Codes sub-registry is as follows:
警告代码子注册表中的注释如下：
Warning codes provide information supplemental to the status code in SIP response messages.
警告代码提供SIP响应消息中状态代码的补充信息。
The author would like to thank Jon Peterson, Cullen Jennings, Jonathan Rosenberg, John Elwell, Paul Kyzivat, Eric Rescorla, Robert Sparks, Rifaat Shekh-Yusef, Peter Reissner, Tina Tsou, Keith Drage, Brian Stucker, Patrick Ma, Lavis Zhou, Joel Halpern, Hisham Karthabil, Dean Willis, Eric Tremblay, Hans Persson, and Ben Campbell for their careful review and input. Many thanks to Rohan Mahy for helping me with the subtleties of [RFC5626].
作者要感谢乔恩·彼得森、卡伦·詹宁斯、乔纳森·罗森博格、约翰·埃尔维尔、保罗·基齐瓦特、埃里克·雷索拉、罗伯特·斯帕克斯、里法特·谢赫·尤塞夫、彼得·赖斯纳、蒂娜·邹、基思·德拉奇、布赖恩·斯图克、帕特里克·马、拉维斯·周、乔尔·哈尔彭、希沙姆·卡尔塔比尔、迪安·威利斯、埃里克·特雷布雷、汉斯·佩尔森、，和Ben Campbell，感谢他们的仔细审查和投入。非常感谢Rohan Mahy帮助我了解[RFC5626]的微妙之处。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
[RFC5626] Jennings, C., "Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)", RFC 5626, October 2009.
[RFC5626]Jennings，C.，“在会话启动协议（SIP）中管理客户端启动的连接”，RFC 5626，2009年10月。
[RFC2543] Handley, M., Schulzrinne, H., Schooler, E., and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999.
[RFC2543]Handley，M.，Schulzrinne，H.，Schooler，E.，和J.Rosenberg，“SIP：会话启动协议”，RFC 25431999年3月。
[RFC3327] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts", RFC 3327, December 2002.
[RFC3327]Willis，D.和B.Hoeneisen，“用于注册非相邻联系人的会话启动协议（SIP）扩展头字段”，RFC 3327，2002年12月。
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[RFC3515]Sparks，R.，“会话启动协议（SIP）引用方法”，RFC3515，2003年4月。
[RFC3608] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) Extension Header Field for Service Route Discovery During Registration", RFC 3608, October 2003.
[RFC3608]Willis，D.和B.Hoeneisen，“注册期间服务路由发现的会话启动协议（SIP）扩展头字段”，RFC 3608，2003年10月。
[RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, "Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, April 2004.
[RFC3725]Rosenberg，J.，Peterson，J.，Schulzrinne，H.，和G.Camarillo，“会话启动协议（SIP）中第三方呼叫控制（3pcc）的当前最佳实践”，BCP 85，RFC 37252004年4月。
[RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation Protocol (SIP) "Replaces" Header", RFC 3891, September 2004.
[RFC3891]Mahy，R.，Biggs，B.，和R.Dean，“会话启动协议（SIP）”取代了RFC 38912004年9月的“头”。
[RFC3893] Peterson, J., "Session Initiation Protocol (SIP) Authenticated Identity Body (AIB) Format", RFC 3893, September 2004.
[RFC3893]Peterson，J.，“会话启动协议（SIP）认证身份主体（AIB）格式”，RFC 3893，2004年9月。
[RFC3911] Mahy, R. and D. Petrie, "The Session Initiation Protocol (SIP) "Join" Header", RFC 3911, October 2004.
[RFC3911]Mahy，R.和D.Petrie，“会话启动协议（SIP）”加入“头”，RFC 3911，2004年10月。
[RFC4168] Rosenberg, J., Schulzrinne, H., and G. Camarillo, "The Stream Control Transmission Protocol (SCTP) as a Transport for the Session Initiation Protocol (SIP)", RFC 4168, October 2005.
[RFC4168]Rosenberg，J.，Schulzrinne，H.，和G.Camarillo，“作为会话启动协议（SIP）传输的流控制传输协议（SCTP）”，RFC 4168，2005年10月。
[RFC4244] Barnes, M., "An Extension to the Session Initiation Protocol (SIP) for Request History Information", RFC 4244, November 2005.
[RFC4244]Barnes，M.，“请求历史信息会话启动协议（SIP）的扩展”，RFC 4244，2005年11月。
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006.
[RFC4474]Peterson，J.和C.Jennings，“会话启动协议（SIP）中身份验证管理的增强”，RFC 4474，2006年8月。
[RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User Agent URIs (GRUU) in the Session Initiation Protocol (SIP)", RFC 5627, October 2009.
[RFC5627]Rosenberg，J.“在会话启动协议（SIP）中获取和使用全局可路由用户代理URI（GRUU）”，RFC 5627，2009年10月。
In order to support the material in this document, this section makes corrections to RFC 3261.
为了支持本文件中的材料，本节对RFC 3261进行了更正。
The last sentence of the fifth paragraph of Section 8.1.3.5 is replaced by:
将第8.1.3.5节第五段的最后一句替换为：
The client SHOULD retry the request, this time, using a SIP URI unless the original Request-URI used a SIPS scheme, in which case the client MUST NOT retry the request automatically.
客户端应使用SIPURI重试请求，这一次，除非原始请求URI使用SIPS方案，在这种情况下，客户端不得自动重试请求。
The fifth paragraph of Section 10.2.1 is replaced by:
第10.2.1节第五段替换为：
If the Address of Record in the To header field of a REGISTER request is a SIPS URI, then the UAC MUST also include only SIPS URIs in any Contact header field value in the requests.
如果注册请求的To头字段中的记录地址是SIPS URI，则UAC还必须在请求中的任何联系人头字段值中仅包括SIPS URI。
In Section 16.7 on p. 112 describing Record-Route, the second paragraph is deleted.
第16.7节第。112描述记录路线时，删除第二段。
The last paragraph of Section 19.1 is reworded as follows:
第19.1节最后一段改写如下：
A SIPS URI specifies that the resource be contacted securely. This means, in particular, that TLS is to be used on each hop between the UAC and the resource identified by the target SIPS URI. Any resources described by a SIP URI (...)
SIPS URI指定安全地联系资源。这特别意味着，将在UAC和目标SIPS URI标识的资源之间的每个跃点上使用TLS。由SIPURI（…）描述的任何资源
In the third paragraph of Section 20.43, the words "the session description" in the first sentence are replaced with "SIP". Later in the paragraph, "390" is replaced with "380", and "miscellaneous warnings" is replaced with "miscellaneous SIP-related warnings".
在第20.43节第三段中，将第一句中的“会话描述”替换为“SIP”。在本段后面，“390”替换为“380”，“杂项警告”替换为“杂项SIP相关警告”。
The second paragraph of Section 26.2.2 is reworded as follows:
第26.2.2节第二段改写如下：
(...) When used as the Request-URI of a request, the SIPS scheme signifies that each hop over which the request is forwarded, until the request reaches the resource identified by the Request-URI, is secured with TLS. When used by the originator of a request (as would be the case if they employed a SIPS URI as the address-of-record of the target), SIPS dictates that the entire request path to the target domain be so secured.
（…）当用作请求的请求URI时，SIPS方案表示在请求到达由请求URI标识的资源之前，转发请求的每个跃点都由TLS保护。当请求的发起者使用SIPS时（如果他们使用SIPS URI作为目标的记录地址，情况就是这样），SIPS指示到目标域的整个请求路径都是如此安全的。
The first paragraph of Section 26.4.4 is replaced by the following:
第26.4.4节第一段替换为以下内容：
Actually using TLS on every segment of a request path entails that the terminating UAS is reachable over TLS (by registering with a SIPS URI as a contact address). The SIPS scheme implies
实际上，在请求路径的每个段上使用TLS意味着可以通过TLS访问终止UAS（通过将SIPS URI注册为联系地址）。SIPS计划意味着
transitive trust. Obviously, there is nothing that prevents proxies from cheating. Thus, SIPS cannot guarantee that TLS usage will be truly respected end-to-end on each segment of a request path. Note that since many UAs will not accept incoming TLS connections, even those UAs that do support TLS will be required to maintain persistent TLS connections as described in the TLS limitations section above in order to receive requests over TLS as a UAS.
传递信任。显然，没有什么可以阻止代理作弊。因此，SIPS不能保证在请求路径的每个段上真正尊重TLS的端到端使用。请注意，由于许多UAs不会接受传入的TLS连接，因此，即使那些支持TLS的UAs也需要按照上面TLS限制部分中的描述维护持久的TLS连接，以便作为UAs通过TLS接收请求。
The first sentence of the third paragraph of Section 26.4.4 is replaced by the following:
第26.4.4节第三段第一句替换为：
Ensuring that TLS will be used for all of the request segments up to the target UAS is somewhat complex.
确保TLS将用于目标UAS之前的所有请求段有些复杂。
The fourth paragraph of Section 26.4.4 is deleted.
删除第26.4.4节第四段。
The last sentence of the fifth paragraph of Section 26.4.4 is reworded as follows:
第26.4.4节第五段的最后一句改写如下：
S/MIME or, preferably, [RFC4474] may also be used by the originating UAC to help ensure that the original form of the To header field is carried end-to-end.
S/MIME或优选地，[RFC4474]也可由始发UAC使用，以帮助确保端到端携带to报头字段的原始形式。
In the third paragraph of Section 27.2, the phrase "when the failure of the transaction results from a Session Description Protocol (SDP) (RFC 2327 [1]) problem" is deleted.
在第27.2节的第三段中，删除了短语“当事务失败是由会话描述协议（SDP）（RFC 2327[1]）问题引起时”。
In the fifth paragraph of Section 27.2, "390" is replaced with "380", and "miscellaneous warnings" is replaced with "miscellaneous SIP-related warnings".
在第27.2节第五段中，“390”替换为“380”，“杂项警告”替换为“杂项SIP相关警告”。
Author's Address
作者地址
Francois Audet Skype Labs
弗朗索瓦·奥德特Skype实验室
EMail: francois.audet@skypelabs.com
EMail: francois.audet@skypelabs.com