Network Working Group C. Jennings
Request for Comments: 4458 Cisco Systems
Category: Informational F. Audet
Nortel Networks
J. Elwell
Siemens plc
April 2006
Network Working Group C. Jennings
Request for Comments: 4458 Cisco Systems
Category: Informational F. Audet
Nortel Networks
J. Elwell
Siemens plc
April 2006
Session Initiation Protocol (SIP) URIs for Applications such as Voicemail and Interactive Voice Response (IVR)
用于语音邮件和交互式语音响应（IVR）等应用程序的会话启动协议（SIP）URI
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
The Session Initiation Protocol (SIP) is often used to initiate connections to applications such as voicemail or interactive voice recognition systems. This specification describes a convention for forming SIP service URIs that request particular services based on redirecting targets from such applications.
会话启动协议（SIP）通常用于启动与语音邮件或交互式语音识别系统等应用程序的连接。本规范描述了用于形成SIP服务URI的约定，该URI基于来自此类应用程序的重定向目标请求特定服务。
Table of Contents
目录
1. Introduction ....................................................3
2. Mechanism (User Agent Server and Proxy) .........................4
2.1. Target .....................................................4
2.2. Cause ......................................................4
2.3. Retrieving Messages ........................................5
3. Interaction with Request History Information ....................5
4. Limitations of Voicemail URI ....................................6
5. Syntax ..........................................................6
6. Examples ........................................................7
6.1. Proxy Forwards Busy to Voicemail ...........................7
6.2. Endpoint Forwards Busy to Voicemail ........................9
6.3. Endpoint Forwards Busy to TDM via a Gateway ...............11
6.4. Endpoint Forwards Busy to Voicemail with History Info .....13
6.5. Zero Configuration UM System ..............................14
6.6. Call Coverage .............................................15
7. IANA Considerations ............................................15
8. Security Considerations ........................................16
8.1. Integrity Protection of Forwarding in SIP .................16
8.2. Privacy Related Issues on the Second Call Leg .............17
9. Acknowledgements ...............................................18
10. References ....................................................18
10.1. Normative References .....................................18
10.2. Informative References ...................................18
1. Introduction ....................................................3
2. Mechanism (User Agent Server and Proxy) .........................4
2.1. Target .....................................................4
2.2. Cause ......................................................4
2.3. Retrieving Messages ........................................5
3. Interaction with Request History Information ....................5
4. Limitations of Voicemail URI ....................................6
5. Syntax ..........................................................6
6. Examples ........................................................7
6.1. Proxy Forwards Busy to Voicemail ...........................7
6.2. Endpoint Forwards Busy to Voicemail ........................9
6.3. Endpoint Forwards Busy to TDM via a Gateway ...............11
6.4. Endpoint Forwards Busy to Voicemail with History Info .....13
6.5. Zero Configuration UM System ..............................14
6.6. Call Coverage .............................................15
7. IANA Considerations ............................................15
8. Security Considerations ........................................16
8.1. Integrity Protection of Forwarding in SIP .................16
8.2. Privacy Related Issues on the Second Call Leg .............17
9. Acknowledgements ...............................................18
10. References ....................................................18
10.1. Normative References .....................................18
10.2. Informative References ...................................18
Many applications such as Unified Messaging (UM) systems and Interactive Voice Recognition (IVR) systems have been developed out of traditional telephony. They can be used for storing and interacting with voice, video, faxes, email, and instant messaging services. Users often use SIP to initiate communications with these applications. When a SIP call is routed to an application, it is necessary that the application be able to obtain several bits of information from the session initiation message so that it can deliver the desired services.
许多应用程序，如统一消息（UM）系统和交互式语音识别（IVR）系统，都是在传统电话技术的基础上开发出来的。它们可用于存储语音、视频、传真、电子邮件和即时消息服务并与之交互。用户通常使用SIP启动与这些应用程序的通信。当SIP呼叫被路由到应用程序时，应用程序必须能够从会话启动消息中获得几位信息，以便能够提供所需的服务。
For the purpose of this document, we will use UM as the main example, but other applications may use the mechanism defined in this document. The UM needs to know what mailbox should be used and possible reasons for the type of service desired from the UM. Many voicemail systems provide different greetings depending whether the call went to voicemail because the user was busy or because the user did not answer. All of this information can be delivered in existing SIP signaling from the call control that retargets the call to the UM, but there are no conventions for describing how the desired mailbox and the service requested are expressed. It would be possible for every vendor to make this configurable so that any site could get it to work; however, this approach is unrealistic for achieving interoperability among call control, gateway, and unified messaging systems from different vendors. This specification describes a convention for describing this mailbox and service information in the SIP URI so that vendors and operators can build interoperable systems.
在本文档中，我们将使用UM作为主要示例，但其他应用程序可能使用本文档中定义的机制。UM需要知道应该使用什么邮箱，以及从UM获得所需服务类型的可能原因。许多语音邮件系统提供不同的问候语，这取决于呼叫是因为用户忙还是因为用户没有应答而转到语音邮件。所有这些信息都可以在现有的SIP信令中从呼叫控制发送，该呼叫控制将呼叫重定目标到UM，但是没有用于描述所需邮箱和所请求服务的表示方式的约定。每个供应商都有可能对其进行配置，以便任何站点都能使其工作；然而，这种方法对于实现来自不同供应商的呼叫控制、网关和统一消息系统之间的互操作性是不现实的。本规范描述了在SIP URI中描述此邮箱和服务信息的约定，以便供应商和运营商可以构建可互操作的系统。
If there were no need to interoperate with Time Division Multiplexing (TDM)-based voicemail systems or to allow TDM systems to use VoIP unified messaging systems, this problem would be a little easier to solve. The problem that is introduced in the Voice over IP (VoIP) to TDM case is as follows. The SIP system needs to tell a Public Switched Telephone Network (PSTN) gateway both the subscriber's mailbox identifier (which typically looks like a phone number) and the address of the voicemail system in the TDM network (again a phone number).
如果不需要与基于时分多路复用（TDM）的语音邮件系统进行互操作，或者允许TDM系统使用VoIP统一消息系统，那么这个问题将更容易解决。IP语音（VoIP）到TDM案例中引入的问题如下。SIP系统需要告诉公共交换电话网（PSTN）网关用户的邮箱标识符（通常看起来像电话号码）和TDM网络中语音邮件系统的地址（同样是电话号码）。
The question has been asked why the To header cannot be used to specify which mailbox to use. One problem is that the call control proxies cannot modify the To header, and the User Agent Clients (UACs) often set it incorrectly because they do not have information about the subscribers in the domain they are trying to call. This happens because the routing of the call often translates the URI multiple times before it results in an identifier for the desired user that is valid in the namespace that the UM system understands.
问题是，为什么不能使用“收件人”标题指定要使用的邮箱。一个问题是，呼叫控制代理无法修改To头，用户代理客户端（UAC）通常设置不正确，因为它们没有关于试图呼叫的域中订户的信息。发生这种情况的原因是，调用的路由通常会多次转换URI，然后才能生成所需用户的标识符，该标识符在UM系统理解的命名空间中有效。
The mechanism works by encoding the information for the desired service in the SIP Request-URI that is sent to the UM system. Two chunks of information are encoded, the first being the target mailbox to use and the second being the SIP status code that caused this retargeting and that indicates the desired service. The userinfo and hostport parts of the Request-URI will identify the voicemail service, the target mailbox can be put in the target parameter, and the reason can be put in the cause parameter. For example, if the proxy wished to use Bob's mailbox because his phone was busy, the URI sent to the UM system could be something like:
该机制通过在发送到UM系统的SIP请求URI中编码所需服务的信息来工作。对两个信息块进行编码，第一个是要使用的目标邮箱，第二个是导致此重定目标并指示所需服务的SIP状态码。请求URI的userinfo和hostport部分将标识语音邮件服务，目标邮箱可以放在目标参数中，原因可以放在原因参数中。例如，如果代理希望使用Bob的邮箱，因为他的手机忙，则发送到UM系统的URI可能类似于：
sip:voicemail@example.com;target=bob%40example.com;cause=486
sip:voicemail@example.com;target=bob%40example.com;cause=486
Target is a URI parameter that indicates the address of the retargeting entity: in the context of UM, this can be the mailbox number. For example, in the case of a voicemail system on the PSTN, the user portion will contain the phone number of the voicemail system, while the target will contain the phone number of the subscriber's mailbox.
Target是一个URI参数，指示重定目标实体的地址：在UM上下文中，这可以是邮箱号。例如，在PSTN上的语音邮件系统的情况下，用户部分将包含语音邮件系统的电话号码，而目标将包含订户邮箱的电话号码。
Cause is a URI parameter that is used to indicate the service that the User Agent Server (UAS) receiving the message should perform. The following values for this URI parameter are defined:
原因是一个URI参数，用于指示接收消息的用户代理服务器（UAS）应执行的服务。定义了此URI参数的以下值：
+---------------------------------+-------+
| Redirecting Reason | Value |
+---------------------------------+-------+
| Unknown/Not available | 404 |
| User busy | 486 |
| No reply | 408 |
| Unconditional | 302 |
| Deflection during alerting | 487 |
| Deflection immediate response | 480 |
| Mobile subscriber not reachable | 503 |
+---------------------------------+-------+
+---------------------------------+-------+
| Redirecting Reason | Value |
+---------------------------------+-------+
| Unknown/Not available | 404 |
| User busy | 486 |
| No reply | 408 |
| Unconditional | 302 |
| Deflection during alerting | 487 |
| Deflection immediate response | 480 |
| Mobile subscriber not reachable | 503 |
+---------------------------------+-------+
The mapping to PSTN protocols is important both for gateways that connect the IP network to existing TDM customer's equipment, such as Private Branch Exchanges (PBXs) and voicemail systems, and for gateways that connect the IP network to the PSTN network. Integrated Services Digital Network User Part (ISUP) has signaling encodings for
PSTN协议的映射对于将IP网络连接到现有TDM客户设备（如专用分支交换机（PBX）和语音邮件系统）的网关以及将IP网络连接到PSTN网络的网关都很重要。综合业务数字网络用户部分（ISUP）具有用于
this information that can be treated as roughly equivalent for the purposes here. For this reason, this specification uses the names of Redirecting Reason values defined in ITU-T Q.732.2-5 [8]. In this specification, the Redirecting Reason Values are referred to as "Causes". It should be understood that the term "Cause" has nothing to do with PSTN "Cause values" (as per ITU-T Q.850 [9] and RFC 3398 [5]) but are instead mapped to ITU-T Q.732.2-5 Redirecting Reasons. Since ISUP interoperates with other PSTN networks, such as Q.931 [10] and QSIG [11], using well-known rules, it makes sense to use the ISUP names as the most appropriate superset. If no appropriate mapping to a cause value defined in this specification exists in a network, it would be mapped to 302 "Unconditional". Similarly, if the mapping occurs from one of the causes defined in this specification to a PSTN system that does not have an equivalent reason value, it would be mapped to that network's equivalent of "Unconditional". If a new cause parameter needs to be defined, this specification will have to be updated.
这些信息可以大致等同于此处的目的。因此，本规范使用了ITU-T Q.732.2-5[8]中定义的重定向原因值的名称。在本规范中，重定向原因值称为“原因”。应该理解，术语“原因”与PSTN“原因值”（根据ITU-T Q.850[9]和RFC 3398[5]）无关，而是映射到ITU-T Q.732.2-5重定向原因。由于ISUP与其他PSTN网络（如Q.931[10]和QSIG[11]）使用众所周知的规则进行互操作，因此使用ISUP名称作为最合适的超集是有意义的。如果网络中不存在与本规范中定义的原因值的适当映射，则将映射到302“无条件”。类似地，如果从本规范中定义的原因之一映射到没有等效原因值的PSTN系统，则将映射到该网络的等效“无条件”。如果需要定义新的原因参数，则必须更新本规范。
The user portion of the URI SHOULD be used as the address of the voicemail system on the PSTN, while the target SHOULD be mapped to the original redirecting number on the PSTN side.
URI的用户部分应该用作PSTN上语音邮件系统的地址，而目标应该映射到PSTN端的原始重定向号码。
The redirection counters SHOULD be set to one unless additional information is available.
除非有其他可用信息，否则重定向计数器应设置为1。
The UM system MAY use the fact that the From header is the same as the URI target as a hint that the user wishes to retrieve messages.
UM系统可以使用From头与URI目标相同这一事实作为用户希望检索消息的提示。
The Request History mechanism [6] provides more information relating to multiple retargetings. It is reasonable to have systems in which both the information in this specification and the History information are included and one or both are used.
请求历史机制[6]提供了与多个重定目标相关的更多信息。系统中应同时包含本规范中的信息和历史信息，并使用其中一种或两种信息。
History-Info specifies a means of providing the UAS and UAC with information about the retargeting of a request. This information includes the initial Request-URI and any retarget-to URIs. This information is placed in the History-Info header field, which, except where prevented by privacy considerations, is built up as the request progresses and, upon reaching the UAS, is returned in certain responses.
历史信息指定向UAS和UAC提供请求重定目标信息的方法。此信息包括初始请求URI和对URI的任何重定目标。该信息被放置在历史信息标题字段中，除非出于隐私考虑，否则该字段会随着请求的进行而建立，并且在到达UAS时，会在某些响应中返回。
History-Info, when deployed at relevant SIP entities, is intended to provide a comprehensive trace of retargeting for a SIP request, along with the SIP response codes that led to retargeting.
当在相关SIP实体上部署历史信息时，其目的是提供SIP请求重定目标的全面跟踪，以及导致重定目标的SIP响应代码。
History-Info can complement this specification. In particular, when a proxy inserts a URI containing the parameters defined in this specification into the Request-URI of a forwarded request, the proxy can also insert a History-Info header field entry into the forwarded request, and the URI in that entry will incorporate these parameters. Therefore, even if the Request-URI is replaced as a result of rerouting by a downstream proxy, the History-Info header field will still contain these parameters, which may be of use to the UAS. Consequently, UASes that make use of this information may find the information in the History-Info header and/or in the Request-URI, depending on the capability of the proxy to support generation of History-Info or on the behavior of downstream proxies; therefore, applications need to take this into account.
历史信息可以补充此规范。特别是，当代理将包含本规范中定义的参数的URI插入转发请求的请求URI时，代理还可以将历史信息头字段条目插入转发请求，并且该条目中的URI将包含这些参数。因此，即使请求URI由于下游代理的重新路由而被替换，历史信息头字段仍将包含这些参数，这些参数可能对UAS有用。因此，根据代理支持历史信息生成的能力或下游代理的行为，使用该信息的uas可以在历史信息报头和/或请求URI中找到该信息；因此，应用程序需要考虑这一点。
This specification requires the proxy that is requesting the service to understand whether the UM system it is targeting supports the syntax defined in this specification. Today, this information is provided to the proxy by configuration. For practical purposes, this means that the approach is unlikely to work in cases in which the proxy is not configured with information about the UM system or in which the UM is not in the same administrative domain.
此规范要求请求服务的代理了解其目标UM系统是否支持此规范中定义的语法。现在，这些信息是通过配置提供给代理的。出于实际目的，这意味着在代理未配置有关UM系统的信息或UM不在同一管理域的情况下，该方法不太可能起作用。
This approach only works when the service that the call control wants applied is fairly simple. For example, it does not allow the proxy to express information like "Do not offer to connect to the target's colleague because that address has already been tried".
只有当调用控制想要应用的服务相当简单时，这种方法才有效。例如，它不允许代理表达诸如“由于已尝试该地址，因此不提供与目标同事的连接”之类的信息。
The limitations discussed in this section are addressed by History-Info [6].
本节讨论的限制由历史信息[6]解决。
The ABNF[4] grammar for these parameters is shown below. The definitions of pvalue and Status-Code are defined in the ABNF in RFC 3261[1].
这些参数的ABNF[4]语法如下所示。pvalue和状态代码的定义见RFC 3261[1]中的ABNF。
target-param = "target" EQUAL pvalue
target param=“target”等于pvalue
cause-param = "cause" EQUAL Status-Code
原因参数=“原因”相等状态代码
Note that the ABNF requires some characters to be escaped if they occur in the value of the target parameters. For example, the "@" character needs to be escaped.
请注意，如果目标参数的值中出现某些字符，ABNF需要对其进行转义。例如，需要转义“@”字符。
This section provides some example use cases for the solution proposed in this document. For the purpose of this document, UM is used as the main example, but other applications may use this mechanism. The examples are intended to highlight the potential applicability of this solution and are not intended to limit its applicability.
本节提供了本文档中提出的解决方案的一些示例用例。在本文档中，UM用作主要示例，但其他应用程序可能使用此机制。这些示例旨在强调该解决方案的潜在适用性，而不是限制其适用性。
Also, the examples show just service retargeting on busy, but can easily be adapted to show other forms of retargeting.
此外，这些示例仅显示忙时的服务重定目标，但可以轻松地调整以显示其他形式的重定目标。
In several of the examples, the URIs are broken across more than one line. This was only done for formatting and is not a valid SIP message. Some of the characters in the URIs are not correctly escaped to improve readability. The examples are all shown using sip: with UDP transport, for readability. It should be understood that using sips: with TLS transport is preferable.
在几个示例中，URI被拆分为多行。这仅用于格式化，不是有效的SIP消息。URI中的某些字符没有正确转义以提高可读性。为了可读性，所有示例都使用sip:with UDP传输显示。应该理解，最好使用sips:TLS传输。
In this example, Alice calls Bob. Bob's proxy determines that Bob is busy, and the proxy forwards the call to Bob's voicemail. Alice's phone is at 192.0.2.1, while Bob's phone is at 192.0.2.2. The important thing to note is the URI in message F7.
在本例中，Alice调用Bob。Bob的代理确定Bob正忙，代理将呼叫转发到Bob的语音邮件。爱丽丝的电话号码是192.0.2.1，而鲍勃的电话号码是192.0.2.2。需要注意的重要事项是消息F7中的URI。
Alice Proxy Bob voicemail
| | | |
| INVITE F1 | | |
|--------------->| INVITE F2 | |
| |------------->| |
|(100 Trying) F3 | | |
|<---------------| 486 Busy F4 | |
| |<-------------| |
| | ACK F5 | |
| |------------->| |
|(181 Call is Being Forwarded) F6 |
|<---------------| | INVITE F7 |
| |--------------------------------->|
* Rest of flow not shown *
Alice Proxy Bob voicemail
| | | |
| INVITE F1 | | |
|--------------->| INVITE F2 | |
| |------------->| |
|(100 Trying) F3 | | |
|<---------------| 486 Busy F4 | |
| |<-------------| |
| | ACK F5 | |
| |------------->| |
|(181 Call is Being Forwarded) F6 |
|<---------------| | INVITE F7 |
| |--------------------------------->|
* Rest of flow not shown *
F1: INVITE 192.0.2.1 -> proxy.example.com
F1: INVITE 192.0.2.1 -> proxy.example.com
INVITE sip:+15555551002@example.com;user=phone SIP/2.0
Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+15555551002@example.com;user=phone
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sip:alice@192.0.2.1>
Content-Type: application/sdp
Content-Length: *Body length goes here*
INVITE sip:+15555551002@example.com;user=phone SIP/2.0
Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+15555551002@example.com;user=phone
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sip:alice@192.0.2.1>
Content-Type: application/sdp
Content-Length: *Body length goes here*
* SDP goes here*
* SDP在这里*
F2: INVITE proxy.example.com -> 192.0.2.2
F2: INVITE proxy.example.com -> 192.0.2.2
INVITE sip:+15555551002@192.0.2.2 SIP/2.0
Via: SIP/2.0/TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-1
Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+15555551002@example.com;user=phone
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sip:alice@192.0.2.1>
Content-Type: application/sdp
Content-Length: *Body length goes here*
INVITE sip:+15555551002@192.0.2.2 SIP/2.0
Via: SIP/2.0/TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-1
Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+15555551002@example.com;user=phone
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sip:alice@192.0.2.1>
Content-Type: application/sdp
Content-Length: *Body length goes here*
* SDP goes here*
* SDP在这里*
F4: 486 192.0.2.2 -> proxy.example.com
F4: 486 192.0.2.2 -> proxy.example.com
SIP/2.0 486 Busy Here
Via: SIP/2.0/TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-1
Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+15555551002@example.com;user=phone;tag=09xde23d80
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Content-Length: 0
SIP/2.0 486 Busy Here
Via: SIP/2.0/TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-1
Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+15555551002@example.com;user=phone;tag=09xde23d80
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Content-Length: 0
F7: INVITE proxy.example.com -> um.example.com
F7: INVITE proxy.example.com -> um.example.com
INVITE sip:voicemail@example.com;\
target=sip:+15555551002%40example.com;user=phone;\
cause=486 SIP/2.0
Via: SIP/2.0/TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-2
Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+15555551002@example.com;user=phone
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sip:alice@192.0.2.1>
Content-Type: application/sdp
Content-Length: *Body length goes here*
INVITE sip:voicemail@example.com;\
target=sip:+15555551002%40example.com;user=phone;\
cause=486 SIP/2.0
Via: SIP/2.0/TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-2
Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+15555551002@example.com;user=phone
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sip:alice@192.0.2.1>
Content-Type: application/sdp
Content-Length: *Body length goes here*
* SDP goes here*
* SDP在这里*
In this example, Alice calls Bob. Bob is busy, but forwards the session directly to his voicemail. Alice's phone is at 192.0.2.1, while Bob's phone is at 192.0.2.2. The important thing to note is the URI in the Contact in message F3.
在本例中，Alice调用Bob。Bob很忙，但将会话直接转发到他的语音信箱。爱丽丝的电话号码是192.0.2.1，而鲍勃的电话号码是192.0.2.2。需要注意的重要事项是消息F3中联系人中的URI。
Alice Proxy Bob voicemail
| | | |
| INVITE F1 | | |
|--------------->| INVITE F2 | |
| |------------->| |
| | 302 Moved F3 | |
| 302 Moved F4 |<-------------| |
|<---------------| | |
| ACK F5 | | |
|--------------->| ACK F6 | |
| |------------->| |
| INVITE F7 |
|-------------------------------------------------->|
* Rest of flow not shown *
Alice Proxy Bob voicemail
| | | |
| INVITE F1 | | |
|--------------->| INVITE F2 | |
| |------------->| |
| | 302 Moved F3 | |
| 302 Moved F4 |<-------------| |
|<---------------| | |
| ACK F5 | | |
|--------------->| ACK F6 | |
| |------------->| |
| INVITE F7 |
|-------------------------------------------------->|
* Rest of flow not shown *
F1: INVITE 192.0.2.1 -> proxy.example.com
F1: INVITE 192.0.2.1 -> proxy.example.com
INVITE sip:+15555551002@example.com;user=phone SIP/2.0
Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+15555551002@example.com;user=phone
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sip:alice@192.0.2.1>
Content-Type: application/sdp
Content-Length: *Body length goes here*
INVITE sip:+15555551002@example.com;user=phone SIP/2.0
Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+15555551002@example.com;user=phone
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sip:alice@192.0.2.1>
Content-Type: application/sdp
Content-Length: *Body length goes here*
* SDP goes here*
* SDP在这里*
F2: INVITE proxy.example.com -> 192.0.2.2
F2: INVITE proxy.example.com -> 192.0.2.2
INVITE sip:line1@192.0.2.2 SIP/2.0
Via: SIP/2.0/TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-1
Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+15555551002@example.com;user=phone
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sip:alice@192.0.2.1>
Content-Type: application/sdp
Content-Length: *Body length goes here*
INVITE sip:line1@192.0.2.2 SIP/2.0
Via: SIP/2.0/TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-1
Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+15555551002@example.com;user=phone
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sip:alice@192.0.2.1>
Content-Type: application/sdp
Content-Length: *Body length goes here*
* SDP goes here*
* SDP在这里*
F3: 302 192.0.2.2 -> proxy.example.com
F3: 302 192.0.2.2 -> proxy.example.com
SIP/2.0 302 Moved Temporarily
Via: SIP/2.0/TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-1
Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+15555551002@example.com;user=phone;tag=09xde23d80
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Contact: <sip: voicemail@example.com;\
target=sip:+15555551002%40example.com;user=phone;\
cause=486;>
Content-Length: 0
SIP/2.0 302 Moved Temporarily
Via: SIP/2.0/TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-1
Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+15555551002@example.com;user=phone;tag=09xde23d80
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Contact: <sip: voicemail@example.com;\
target=sip:+15555551002%40example.com;user=phone;\
cause=486;>
Content-Length: 0
F7: INVITE proxy.example.com -> um.example.com
F7: INVITE proxy.example.com -> um.example.com
INVITE sip: voicemail@example.com;\
target=sip:+15555551002%40example.com;user=phone;\
cause=486 SIP/2.0
Via: SIP/2.0/TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-2
Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+15555551002@example.com;user=phone
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sip:alice@192.0.2.1>
Content-Type: application/sdp
Content-Length: *Body length goes here*
INVITE sip: voicemail@example.com;\
target=sip:+15555551002%40example.com;user=phone;\
cause=486 SIP/2.0
Via: SIP/2.0/TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-2
Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+15555551002@example.com;user=phone
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sip:alice@192.0.2.1>
Content-Type: application/sdp
Content-Length: *Body length goes here*
* SDP goes here*
* SDP在这里*
In this example, the voicemail is reached via a gateway to a TDM network. Bob's number is +1 555 555-1002, while voicemail's number on the TDM network is +1-555-555-2000.
在此示例中，语音邮件通过TDM网络的网关到达。Bob的号码是+1 555 555-1002，而TDM网络上的语音信箱号码是+1-555-555-2000。
The call flow is the same as in Section 6.2 except for the Contact URI in F4 and the Request URI in F7.
除了F4中的联系人URI和F7中的请求URI外，调用流与第6.2节中的相同。
Alice Proxy Bob voicemail
| | | |
| INVITE F1 | | |
|--------------->| INVITE F2 | |
| |------------->| |
|(100 Trying) F3 | | |
|<---------------| 302 Moved F4 | |
| |<-------------| |
| | ACK F5 | |
| |------------->| |
|(181 Call is Being Forwarded) F6 |
|<---------------| | INVITE F7 |
| |--------------------------------->|
* Rest of flow not shown *
Alice Proxy Bob voicemail
| | | |
| INVITE F1 | | |
|--------------->| INVITE F2 | |
| |------------->| |
|(100 Trying) F3 | | |
|<---------------| 302 Moved F4 | |
| |<-------------| |
| | ACK F5 | |
| |------------->| |
|(181 Call is Being Forwarded) F6 |
|<---------------| | INVITE F7 |
| |--------------------------------->|
* Rest of flow not shown *
F4: 486 192.0.2.2 -> proxy.example.com
F4: 486 192.0.2.2 -> proxy.example.com
SIP/2.0 302 Moved temporarily
Via: SIP/2.0/TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-1
Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+15555551002@example.com;user=phone;tag=09xde23d80
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Contact: <sip:+15555552000@example.com;user=phone;\
target=tel:+15555551002;cause=486>
Content-Length: 0
SIP/2.0 302 Moved temporarily
Via: SIP/2.0/TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-1
Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+15555551002@example.com;user=phone;tag=09xde23d80
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Contact: <sip:+15555552000@example.com;user=phone;\
target=tel:+15555551002;cause=486>
Content-Length: 0
F7: INVITE proxy.example.com -> gw.example.com
F7: INVITE proxy.example.com -> gw.example.com
INVITE sip:+15555552000@example.com;user=phone;\
target=tel:+15555551002;cause=486\
SIP/2.0
Via: SIP/2.0/TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-2
Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+15555551002@example.com;user=phone
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sip:alice@192.0.2.1;transport=tcp>
Content-Type: application/sdp
Content-Length: *Body length goes here*
INVITE sip:+15555552000@example.com;user=phone;\
target=tel:+15555551002;cause=486\
SIP/2.0
Via: SIP/2.0/TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-2
Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+15555551002@example.com;user=phone
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sip:alice@192.0.2.1;transport=tcp>
Content-Type: application/sdp
Content-Length: *Body length goes here*
* SDP goes here*
* SDP在这里*
This example illustrates how History Info works in conjunction with service retargeting. The scenario is the same as Section 6.1.
此示例说明了历史信息如何与服务重定目标结合使用。该场景与第6.1节相同。
F1: INVITE 192.0.2.1 -> proxy.example.com
F1: INVITE 192.0.2.1 -> proxy.example.com
INVITE sip:+15555551002@example.com;user=phone SIP/2.0
Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+15555551002@example.com;user=phone
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sip:alice@192.0.2.1>
History-Info: <sip:+15555551002@example.com;user=phone >;index=1
Content-Type: application/sdp
Content-Length: *Body length goes here*
INVITE sip:+15555551002@example.com;user=phone SIP/2.0
Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+15555551002@example.com;user=phone
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sip:alice@192.0.2.1>
History-Info: <sip:+15555551002@example.com;user=phone >;index=1
Content-Type: application/sdp
Content-Length: *Body length goes here*
* SDP goes here*
* SDP在这里*
F2: INVITE proxy.example.com -> 192.0.2.2
F2: INVITE proxy.example.com -> 192.0.2.2
INVITE sip:line1@192.0.2.2 SIP/2.0
Via: SIP/2.0/TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-1
Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+15555551002@example.com;user=phone
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sip:alice@192.0.2.1>
History-Info: <sip:+15555551002@example.com;user=phone >;index=1,
<sip:line1@192.0.2.4>;index=1.1
INVITE sip:line1@192.0.2.2 SIP/2.0
Via: SIP/2.0/TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-1
Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+15555551002@example.com;user=phone
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sip:alice@192.0.2.1>
History-Info: <sip:+15555551002@example.com;user=phone >;index=1,
<sip:line1@192.0.2.4>;index=1.1
Content-Type: application/sdp
Content-Length: *Body length goes here*
Content-Type: application/sdp
Content-Length: *Body length goes here*
* SDP goes here*
* SDP在这里*
F7: INVITE proxy.example.com -> um.example.com
F7: INVITE proxy.example.com -> um.example.com
INVITE sip: voicemail@example.com;\
target=sip:+15555551002%40example.com;user=phone;\
cause=486 SIP/2.0
Via: SIP/2.0/TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-2
Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+15555551002@example.com;user=phone
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sip:alice@192.0.2.1>
History-Info: <sip:+15555551002@example.com;user=phone >;index=1,
<sip:line1@192.0.2.4?Reason=SIP%3Bcause%3D302;\
text="Moved Temporarily">;index=1.1
<sip: voicemail@example.com;\
target=sip:+15555551002%40example.com;user=phone;\
cause=486>;index=2
Contact: <sip:alice@192.0.2.1>
Content-Type: application/sdp
Content-Length: *Body length goes here*
INVITE sip: voicemail@example.com;\
target=sip:+15555551002%40example.com;user=phone;\
cause=486 SIP/2.0
Via: SIP/2.0/TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-2
Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+15555551002@example.com;user=phone
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sip:alice@192.0.2.1>
History-Info: <sip:+15555551002@example.com;user=phone >;index=1,
<sip:line1@192.0.2.4?Reason=SIP%3Bcause%3D302;\
text="Moved Temporarily">;index=1.1
<sip: voicemail@example.com;\
target=sip:+15555551002%40example.com;user=phone;\
cause=486>;index=2
Contact: <sip:alice@192.0.2.1>
Content-Type: application/sdp
Content-Length: *Body length goes here*
* SDP goes here*
* SDP在这里*
In this example, the UM system has no configuration information specific to any user. The proxy is configured to pass a URI that provides the prompt to play and an email address in the user portion of the URI to which the recorded message is to be sent.
在此示例中，UM系统没有特定于任何用户的配置信息。代理被配置为传递一个URI，该URI提供播放提示，并在URI的用户部分中传递一个电子邮件地址，所记录的消息将被发送到该用户部分。
The call flow is the same as in Section 6.1, except that the URI in F7 changes to specify the user part as Bob's email address, and the Netann [7] URI play parameter specifies where the greeting to play can be fetched from.
调用流程与第6.1节中的相同，只是F7中的URI更改为将用户部分指定为Bob的电子邮件地址，而Netann[7]URI play参数指定从何处获取要播放的问候语。
F7: INVITE proxy.example.com -> voicemail.example.com
F7: INVITE proxy.example.com -> voicemail.example.com
INVITE sip:voicemail@example.com;target=mailto:bob%40example.com;\
cause=486;play=http://www.example.com/bob/busy.wav SIP/2.0
Via: SIP/2.0/TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-2
Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15555551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+15555551002@example.com;user=phone
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sip:alice@192.0.2.1>
Content-Type: application/sdp
Content-Length: *Body length goes here*
INVITE sip:voicemail@example.com;target=mailto:bob%40example.com;\
cause=486;play=http://www.example.com/bob/busy.wav SIP/2.0
Via: SIP/2.0/TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-2
Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15555551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+15555551002@example.com;user=phone
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sip:alice@192.0.2.1>
Content-Type: application/sdp
Content-Length: *Body length goes here*
* SDP goes here*
* SDP在这里*
In addition, if the proxy wished to indicate a Voice XML (VXML) script that the UM should execute, it could add a parameter to the URI in the above message that looked like:
此外，如果代理希望指示UM应该执行的语音XML（VXML）脚本，它可以在上述消息中向URI添加一个参数，如下所示：
voicexml=http://www.example.com/bob/busy.vxml
voicexml=http://www.example.com/bob/busy.vxml
In a Call Coverage example, a user on the PSTN calls an 800 number. The gateway sends this to the proxy, which recognizes that the helpdesk is the target. Alice and Bob are staffing the help desk and are tried sequentially, but neither answers, so the call is forwarded to the helpdesk's voicemail.
在呼叫覆盖率示例中，PSTN上的用户呼叫800号码。网关将此消息发送到代理，代理将识别帮助台是目标。Alice和Bob正在为帮助台配备人员，并按顺序进行了尝试，但两人都没有接听，因此呼叫被转发到帮助台的语音信箱。
The details of this flow are trivial and not shown. The key item in this example is that the INVITE to Alice and Bob looks as follows:
这个流程的细节很琐碎，没有显示出来。本例中的关键项是邀请Alice和Bob如下所示：
INVITE sip:voicemail@example.com;target=helpdesk%40example.com;\
cause=302 SIP/2.0
INVITE sip:voicemail@example.com;target=helpdesk%40example.com;\
cause=302 SIP/2.0
This specification adds two new values to the IANA registration in the "SIP/SIPS URI Parameters" registry as defined in [3].
本规范向[3]中定义的“SIP/SIPS URI参数”注册表中的IANA注册添加了两个新值。
Parameter Name Predefined Values Reference
____________________________________________
target No [RFC4458]
cause Yes [RFC4458]
Parameter Name Predefined Values Reference
____________________________________________
target No [RFC4458]
cause Yes [RFC4458]
This document discusses transactions involving at least three parties, which increases the complexity of the privacy issues.
本文件讨论了至少涉及三方的交易，这增加了隐私问题的复杂性。
The new URI parameters defined in this document are generally sent from a Proxy or call control system to a Unified Messaging (UM) system or to a gateway to the PSTN and then to a voicemail system. These new parameters tell the UM what service the proxy wishes to have performed. Just as any message sent from the proxy to the UM needs to be integrity protected, these messages need to be integrity protected to stop attackers from, for example, causing a voicemail meant for a company's CEO to go to an attacker's mailbox. RFC 3261 provides a TLS mechanism suitable for performing this integrity protection.
本文档中定义的新URI参数通常从代理或呼叫控制系统发送到统一消息（UM）系统或PSTN网关，然后发送到语音邮件系统。这些新参数告诉UM代理希望执行的服务。正如从代理发送到UM的任何消息都需要受到完整性保护一样，这些消息也需要受到完整性保护，以防止攻击者（例如）将公司CEO的语音邮件发送到攻击者的邮箱。RFC 3261提供了适用于执行此完整性保护的TLS机制。
The signaling from the Proxy to the UM or gateway will reveal who is calling whom and possibly some information about a user's presence based on whether the call was answered or sent to voicemail. This information can be protected by encrypting the SIP traffic between the Proxy and UM or gateway. Again, RFC 3261 contains mechanisms for accomplishing this using TLS.
从代理到UM或网关的信令将根据呼叫是否被应答或发送到语音邮件来揭示谁在呼叫谁，以及可能的一些关于用户存在的信息。可以通过加密代理和UM或网关之间的SIP通信来保护此信息。同样，RFC3261包含使用TLS实现这一点的机制。
Implementations should implement and use TLS.
实现应该实现并使用TLS。
The forwarding of a call in SIP brings up a very strange trust issue. Consider the normal case -- A calls B and the call gets forwarded to C by a network element in B's domain, and then C answers the call. A has called B but ended up talking to C. This scenario may be hard to separate from a man-in-the-middle attack.
SIP中呼叫的转发带来了一个非常奇怪的信任问题。考虑正常情况——呼叫B和呼叫通过B域中的网络元素转发到C，然后C应答呼叫。A打电话给B，但最终与C交谈。这种情况可能很难与中间人攻击区分开来。
There are two possible solutions. One is that B sends back information to A saying don't call me, call C, and signs it as B. The problem is that this solution involves revealing that B has forwarded to C, which B often may not want to do. For example, B may be a work phone that has been forwarded to a mobile or home phone. The user does not want to reveal their mobile or home phone number but, even more importantly, does not want to reveal that they are not in the office.
有两种可能的解决办法。一个是B向A发回信息，说“不要打电话给我，打电话给C”，并将其签名为B。问题是，这个解决方案涉及到透露B已转发给C，而B通常不想这样做。例如，B可以是已经转发到移动电话或家庭电话的工作电话。用户不想透露他们的手机或家庭电话号码，但更重要的是，不想透露他们不在办公室。
The other possible solution is that A needs to trust B only to forward to a trusted identity. This requires a hop-by-hop transitive trust such that each hop will only send to a trusted next hop and each hop will only do things that the user at that hop desired. This
另一种可能的解决方案是，A只需要信任B就可以转发到受信任的身份。这需要一个逐跳的可传递信任，这样每个跃点将只发送到受信任的下一个跃点，并且每个跃点只做该跃点上的用户希望做的事情。这
solution is enforced in SIP using the SIPS URI and TLS-based hop-by-hop security. It protects from an off-axis attack, but if one of the hops is not trustworthy, the call may be diverted to an attacker.
该解决方案在SIP中使用SIPS URI和基于TLS的逐跳安全性实施。它可以防止离轴攻击，但如果其中一个跃点不可信，则呼叫可能会转移到攻击者。
Any redirection of a call to an attacker's mailbox is serious. It is trivial for an attacker to make its mailbox seem very much like the real mailbox and forward the messages to the real mailbox so that the fact that the messages have been intercepted or even tampered with escapes detection. Approaches such as the SIPS URL and the History-Info[6] can help protect against these attacks.
对攻击者邮箱的任何呼叫重定向都是严重的。攻击者使其邮箱看起来与真实邮箱非常相似，并将邮件转发到真实邮箱，从而使邮件被截获甚至篡改的事实逃脱检测，这对攻击者来说是微不足道的。SIPS URL和历史信息[6]等方法有助于防范这些攻击。
In the case where A calls B and gets redirected to C, occasionally people suggest that there is a requirement for the call leg from B to C to be anonymous. The SIP case is not the PSTN, and there is no call leg from B to C; instead, there is a VoIP session between A and C. If A has put a To header field value containing B in the initial invite message, unless something special is done about it, C would see that To header field value. If the person who answers phone C says "I think you dialed the wrong number; who were you trying to reach?", A will probably specify B.
在A呼叫B并被重定向到C的情况下，有时人们会建议要求B到C的呼叫段是匿名的。SIP案例不是PSTN，从B到C没有呼叫分支；相反，在a和C之间有一个VoIP会话。如果a在初始invite消息中放置了一个包含B的To头字段值，除非对其做了特殊处理，否则C将看到该To头字段值。如果接电话的人说“我想你拨错号码了；你想联系谁？”，A可能会指定B。
If A does not want C to see that the call was to B, A needs a special relationship with the forwarding Proxy to induce it not to reveal that information. The call should go through an anonymization service that provides session or user level privacy (as described in RFC 3323 [2]) service before going to C. It is not hard to figure out how to meet this requirement, but it is unclear why anyone would want this service.
如果A不希望C看到呼叫是对B的，A需要与转发代理建立特殊关系，以使其不泄露该信息。在前往C之前，呼叫应通过提供会话或用户级隐私（如RFC 3323[2]中所述）服务的匿名化服务。不难理解如何满足这一要求，但不清楚为什么有人会想要此服务。
The scenario in which B wants to make sure that C does not see that the call was to B is easier to deal with but a bit weird. The usual argument is that Bill wants to forward his phone to Monica but does not want Monica to find out his phone number. It is hard to imagine that Monica would want to accept all Bill's calls without knowing how to call Bill to complain. The only person Monica will be able to complain to is Hillary, when she tries to call Bill. Several popular web portals will send SMS alert messages about things like stock prices and weather to mobile phone users today. Some of these contain no information about the account on the web portal that initiated them, making it nearly impossible for the mobile phone owner to stop them. This anonymous message forwarding has turned out to be a really bad idea even where no malice is present. Clearly some people are fairly dubious about the need for this, but never mind: let's look at how it is solved.
B希望确保C没有看到对B的调用的场景更容易处理，但有点奇怪。通常的理由是比尔想把他的电话转给莫妮卡，但不想让莫妮卡知道他的电话号码。很难想象莫妮卡会在不知道如何打电话给比尔投诉的情况下接受比尔的所有电话。当莫妮卡试图给比尔打电话时，她唯一可以投诉的人就是希拉里。今天，一些流行的门户网站将向手机用户发送有关股票价格和天气等信息的短信提醒信息。其中一些不包含发起它们的门户网站上的帐户信息，这使得手机所有者几乎不可能阻止它们。即使在没有恶意的情况下，这种匿名消息转发也被证明是一个非常糟糕的主意。显然，有些人对这一点的必要性相当怀疑，但没关系：让我们看看它是如何解决的。
In the general case, the proxy needs to route the call through an anonymization service and everything will be cleaned up. Any anonymization service that performs the "Privacy: Header" Service in RFC 3323 [2] must remove the cause and target URI parameters from the URI. Privacy of the parameters, when they form part of a URI within the History-Info header, is covered in History-Info [6].
在一般情况下，代理需要通过匿名服务路由呼叫，所有内容都将被清除。必须从目标服务中删除“Privacy:rf”URI头中的任何“Privacy:rf”参数。当这些参数构成历史信息头中URI的一部分时，它们的隐私将包含在历史信息[6]中。
This specification does not discuss the security considerations of mapping to a PSTN Gateway. Security implications of mapping to ISUP, for example, are discussed in RFC 3398 [5].
本规范不讨论映射到PSTN网关的安全注意事项。例如，RFC3398[5]中讨论了映射到ISUP的安全含义。
Many thanks to Mary Barnes, Steve Levy, Dean Willis, Allison Mankin, Martin Dolly, Paul Kyzivat, Erick Sasaki, Lyndsay Campbell, Keith Drage, Miguel Garcia, Sebastien Garcin, Roland Jesske, Takumi Ohba, and Rohan Mahy.
非常感谢玛丽·巴恩斯、史蒂夫·利维、迪安·威利斯、艾莉森·曼金、马丁·多利、保罗·基齐瓦特、埃里克·佐佐木、林赛·坎贝尔、基思·德雷奇、米格尔·加西亚、塞巴斯蒂安·加辛、罗兰·杰斯克、大叶拓美和罗汉·马希。
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[1] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[2] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002.
[2] Peterson，J.，“会话启动协议（SIP）的隐私机制”，RFC3323，2002年11月。
[3] Camarillo, G., "The Internet Assigned Number Authority (IANA) Uniform Resource Identifier (URI) Parameter Registry for the Session Initiation Protocol (SIP)", BCP 99, RFC 3969, December 2004.
[3] Camarillo，G.，“会话启动协议（SIP）的Internet分配号码管理局（IANA）统一资源标识符（URI）参数注册表”，BCP 99，RFC 3969，2004年12月。
[4] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[4] Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 42342005年10月。
[5] Camarillo, G., Roach, A., Peterson, J., and L. Ong, "Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol (SIP) Mapping", RFC 3398, December 2002.
[5] Camarillo，G.，Roach，A.，Peterson，J.，和L.Ong，“综合业务数字网（ISDN）用户部分（ISUP）到会话发起协议（SIP）的映射”，RFC 3398，2002年12月。
[6] Barnes, M., "An Extension to the Session Initiation Protocol (SIP) for Request History Information", RFC 4244, November 2005.
[6] Barnes，M.，“请求历史信息会话启动协议（SIP）的扩展”，RFC 4244，2005年11月。
[7] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network Media Services with SIP", RFC 4240, December 2005.
[7] Burger，E.，Van Dyke，J.，和A.Spitzer，“具有SIP的基本网络媒体服务”，RFC 42402005年12月。
[8] "Stage 3 description for call offering supplementary services using signalling system No. 7: Call diversion services", ITU-T Recommendation Q.732.2-5, December 1999.
[8] “使用第7号信令系统提供呼叫补充服务的第3阶段说明：呼叫转移服务”，ITU-T建议Q.732.2-5，1999年12月。
[9] "Usage of cause and location in the Digital Subscriber Signalling System No. 1 and the Signalling System No. 7 ISDN User Part", ITU-T Recommendation Q.850, May 1998.
[9] “数字用户信号发送系统1号和信号发送系统7号ISDN用户部分中原因和位置的使用”，ITU-T建议Q.850，1998年5月。
[10] "ISDN user-network interface layer 3 specification for basic call control", ITU-T Recommendation Q.931, May 1998.
[10] “基本呼叫控制的ISDN用户网络接口第3层规范”，ITU-T建议Q.931，1998年5月。
[11] "Information technology - Telecommunications and information exchange between systems - Private Integrated Services Network - Circuit mode bearer services - Inter-exchange signalling procedures and protocol", ISO/IEC 11572, March 2000.
[11] “信息技术.系统间电信和信息交换.专用综合业务网.电路模式承载业务.交换间信令程序和协议”，ISO/IEC 11572，2000年3月。
Authors' Addresses
作者地址
Cullen Jennings Cisco Systems 170 West Tasman Drive Mailstop SJC-21/2 San Jose, CA 95134 USA
美国加利福尼亚州圣何塞市西塔斯曼大道170号邮递站SJC-21/2库伦詹宁斯思科系统公司，邮编95134
Phone: +1 408 421-9990
EMail: fluffy@cisco.com
Phone: +1 408 421-9990
EMail: fluffy@cisco.com
Francois Audet Nortel Networks 4655 Great America Parkway Santa Clara, CA 95054 US
Francois Audet Nortel Networks 4655美国加利福尼亚州圣克拉拉大美洲大道95054
Phone: +1 408 495 3756
EMail: audet@nortel.com
Phone: +1 408 495 3756
EMail: audet@nortel.com
John Elwell Siemens plc Technology Drive Beeston, Nottingham NG9 1LA UK
英国诺丁汉州比斯顿市约翰·埃尔维尔西门子plc技术大道NG9 1LA
EMail: john.elwell@siemens.com
EMail: john.elwell@siemens.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。