Internet Engineering Task Force (IETF) H. Schulzrinne
Request for Comments: 7090 Columbia University
Category: Standards Track H. Tschofenig
ISSN: 2070-1721
C. Holmberg
Ericsson
M. Patel
Huawei Technologies (UK) Co., Ltd.
April 2014
Internet Engineering Task Force (IETF) H. Schulzrinne
Request for Comments: 7090 Columbia University
Category: Standards Track H. Tschofenig
ISSN: 2070-1721
C. Holmberg
Ericsson
M. Patel
Huawei Technologies (UK) Co., Ltd.
April 2014
Public Safety Answering Point (PSAP) Callback
公共安全应答器（PSAP）回拨
Abstract
摘要
After an emergency call is completed (terminated either prematurely by the emergency caller or normally by the call taker), the call taker may feel the need for further communication. For example, the call may have been dropped by accident without the call taker having sufficient information about the current state of an accident victim. A call taker may trigger a callback to the emergency caller using the contact information provided with the initial emergency call. This callback could, under certain circumstances, be treated like any other call and, as a consequence, it may get blocked by authorization policies or may get forwarded to an answering machine.
紧急呼叫完成后（紧急呼叫人提前终止或通常由呼叫接受者终止），呼叫接受者可能会感到需要进一步沟通。例如，呼叫可能因意外而中断，而呼叫接受者没有关于事故受害者当前状态的足够信息。呼叫接受者可以使用初始紧急呼叫提供的联系信息触发对紧急呼叫者的回调。在某些情况下，此回调可能会被视为与任何其他调用一样，因此，它可能会被授权策略阻止或被转发到应答机。
The IETF emergency services architecture specification already offers a solution approach for allowing Public Safety Answering Point (PSAP) callbacks to bypass authorization policies in order to reach the caller without unnecessary delays. Unfortunately, the specified mechanism only supports limited scenarios. This document discusses shortcomings of the current mechanisms and illustrates additional scenarios where better-than-normal call treatment behavior would be desirable. We describe a solution based on a new header field value for the SIP Priority header field, called "psap-callback", to mark PSAP callbacks.
IETF紧急服务体系结构规范已经提供了一种解决方案方法，允许公共安全应答点（PSAP）回调绕过授权策略，以便在没有不必要延迟的情况下到达呼叫者。不幸的是，指定的机制只支持有限的场景。本文档讨论了当前机制的缺点，并举例说明了需要优于正常呼叫处理行为的其他场景。我们描述了一种基于SIP优先级报头字段的新报头字段值的解决方案，称为“psap回调”，用于标记psap回调。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7090.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7090.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 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 Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
2. Terminology .....................................................5
3. Callback Scenarios ..............................................5
3.1. Routing Asymmetry ..........................................5
3.2. Multi-Stage Routing ........................................7
3.3. Call Forwarding ............................................8
3.4. Network-Based Service URN Resolution ......................10
3.5. PSTN Interworking .........................................11
4. SIP PSAP Callback Indicator ....................................12
4.1. General ...................................................12
4.2. Usage .....................................................12
4.3. Syntax ....................................................12
4.3.1. General ............................................12
4.3.2. ABNF ...............................................12
5. Security Considerations ........................................12
5.1. Security Threat ...........................................12
5.2. Security Requirements .....................................13
5.3. Security Solution .........................................13
6. IANA Considerations ............................................15
7. Acknowledgements ...............................................16
8. References .....................................................16
8.1. Normative References ......................................16
8.2. Informative References ....................................17
1. Introduction ....................................................3
2. Terminology .....................................................5
3. Callback Scenarios ..............................................5
3.1. Routing Asymmetry ..........................................5
3.2. Multi-Stage Routing ........................................7
3.3. Call Forwarding ............................................8
3.4. Network-Based Service URN Resolution ......................10
3.5. PSTN Interworking .........................................11
4. SIP PSAP Callback Indicator ....................................12
4.1. General ...................................................12
4.2. Usage .....................................................12
4.3. Syntax ....................................................12
4.3.1. General ............................................12
4.3.2. ABNF ...............................................12
5. Security Considerations ........................................12
5.1. Security Threat ...........................................12
5.2. Security Requirements .....................................13
5.3. Security Solution .........................................13
6. IANA Considerations ............................................15
7. Acknowledgements ...............................................16
8. References .....................................................16
8.1. Normative References ......................................16
8.2. Informative References ....................................17
Summoning police, the fire department, or an ambulance in emergencies is one of the fundamental and most valuable functions of the telephone. As telephone functionality moves from circuit-switched telephony to Internet telephony, its users rightfully expect that this core functionality will continue to work at least as well as it has for the legacy technology. New devices and services are being made available that could be used to make a request for help and that are not traditional telephones. Users are increasingly expecting them to be used to place emergency calls.
在紧急情况下召集警察、消防部门或救护车是电话最基本和最有价值的功能之一。随着电话功能从电路交换电话转移到互联网电话，其用户理所当然地期望该核心功能将继续工作，至少与传统技术一样。正在提供新的设备和服务，这些设备和服务可用于请求帮助，而不是传统电话。用户越来越希望它们被用来拨打紧急电话。
An overview of the protocol interactions for emergency calling using the IETF emergency services architecture is described in [RFC6443], and [RFC6881] specifies the technical details. As part of the emergency call setup procedure, two important identifiers are conveyed to the PSAP call taker's user agent, namely the address-of-record (AOR), and if available, the Globally Routable User Agent (UA) URIs (GRUUs). RFC 3261 [RFC3261] defines the AOR as:
[RFC6443]中描述了使用IETF紧急服务体系结构进行紧急呼叫的协议交互概述，[RFC6881]规定了技术细节。作为紧急呼叫设置程序的一部分，两个重要标识符被传送到PSAP呼叫接受者的用户代理，即记录地址（AOR）和全局可路由用户代理（UA）URI（GROUS）（如果可用）。RFC 3261[RFC3261]将AOR定义为：
An address-of-record (AOR) is a SIP or SIPS URI that points to a domain with a location service that can map the URI to another URI where the user might be available. Typically, the location service is populated through registrations. An AOR is frequently thought of as the "public address" of the user.
记录地址（AOR）是指向具有位置服务的域的SIP或SIPS URI，该位置服务可以将URI映射到用户可能可用的另一个URI。通常，位置服务是通过注册来填充的。AOR通常被认为是用户的“公共地址”。
In SIP systems, a single user can have a number of user agents (handsets, softphones, voicemail accounts, etc.) that are all referenced by the same AOR. There are a number of cases in which it is desirable to have an identifier that addresses a single user agent rather than the group of user agents indicated by an AOR. The GRUU is such a unique user-agent identifier, and it is also globally routable. [RFC5627] specifies how to obtain and use GRUUs. [RFC6881] also makes use of the GRUU for emergency calls.
在SIP系统中，单个用户可以拥有多个用户代理（手机、软电话、语音信箱帐户等），这些代理都由同一AOR引用。在许多情况下，希望具有针对单个用户代理而不是AOR指示的用户代理组的标识符。GRUU是这样一个唯一的用户代理标识符，它也是全局可路由的。[RFC5627]指定如何获取和使用GROUS。[RFC6881]还利用GRUU进行紧急呼叫。
Regulatory requirements demand that the emergency call setup procedure itself provides enough information to allow the call taker to initiate a callback to the emergency caller. This is desirable in those cases where the call is dropped prematurely or when further communication needs arise. The AOR and the GRUU serve this purpose.
监管要求要求紧急呼叫设置程序本身提供足够的信息，以允许呼叫接受者向紧急呼叫者发起回调。这在呼叫过早中断或需要进一步通信的情况下是可取的。AOR和GRUU就是为了这个目的。
The communication attempt by the PSAP call taker back to the emergency caller is called a "PSAP callback".
PSAP呼叫接受者与紧急呼叫方的通信尝试称为“PSAP回调”。
A PSAP callback may, however, be blocked by user-configured authorization policies or may be forwarded to an answering machine since SIP entities (SIP proxies as well as the SIP user equipment itself) cannot differentiate the PSAP callback from any other SIP call. "Call barring", "do not disturb", or "call diversion" (also called call forwarding) are features that prevent delivery of a call. It is important to note that these features may be implemented by SIP intermediaries as well as by the user agent.
然而，由于SIP实体（SIP代理以及SIP用户设备本身）无法区分PSAP回调与任何其他SIP呼叫，因此PSAP回调可能被用户配置的授权策略阻止，或者可能被转发到应答机。“呼叫限制”、“请勿打扰”或“呼叫转移”（也称为呼叫转移）是阻止呼叫传递的功能。需要注意的是，这些功能可以由SIP中介以及用户代理来实现。
Among the emergency services community, there is a desire to treat PSAP callbacks in such a way that the chances of reaching the emergency caller are increased. At the same time, any solution must minimize the chance that other calls bypass call forwarding or other authorization policies. Ideally, the PSAP callback has to relate to an earlier emergency call that was made "not too long ago". An exact time interval is difficult to define in a global IETF standard due to the variety of national regulatory requirements, but [RFC6881] suggests 30 minutes.
在紧急服务社区中，人们希望以这样一种方式处理PSAP回调，即增加联系紧急呼叫者的机会。同时，任何解决方案都必须将其他呼叫绕过呼叫转移或其他授权策略的可能性降至最低。理想情况下，PSAP回调必须与“不久前”发出的早期紧急呼叫相关。由于国家监管要求的多样性，在全球IETF标准中很难定义准确的时间间隔，但[RFC6881]建议为30分钟。
Nevertheless, to meet the needs from the emergency services community, a basic mechanism for preferential treatment of PSAP callbacks was defined in Section 13 of [RFC6443]. The specification says:
然而，为了满足紧急服务社区的需求，[RFC6443]第13节规定了优先处理PSAP回调的基本机制。说明书上说：
A UA may be able to determine a PSAP callback by examining the domain of incoming calls after placing an emergency call and comparing that to the domain of the answering PSAP from the emergency call. Any call from the same domain and directed to the supplied Contact header or AOR after an emergency call should be accepted as a callback from the PSAP if it occurs within a reasonable time after an emergency call was placed.
UA可以通过在发出紧急呼叫后检查传入呼叫的域并将其与来自紧急呼叫的应答PSAP的域进行比较来确定PSAP回调。如果紧急呼叫发生在紧急呼叫后的合理时间内，则来自同一域并在紧急呼叫后定向到提供的联系人标头或AOR的任何呼叫都应被接受为PSAP的回调。
This approach mimics a stateful packet-filtering firewall and is indeed helpful in a number of cases. It is also relatively simple to implement even though it requires call state to be maintained by the user agent as well as by SIP intermediaries. Unfortunately, the solution does not work in all deployment scenarios. In Section 3 we describe cases where the currently standardized approach is insufficient.
这种方法模仿有状态的包过滤防火墙，在许多情况下确实有用。它的实现也相对简单，尽管它需要由用户代理以及SIP中介维护呼叫状态。不幸的是，该解决方案并不适用于所有部署场景。在第3节中，我们描述了当前标准化方法不足的情况。
Emergency-services-related terminology is borrowed from [RFC5012]. This includes terminology like emergency caller, user equipment, call taker, Emergency Service Routing Proxy (ESRP), and Public Safety Answering Point (PSAP).
应急服务相关术语借用自[RFC5012]。这包括紧急呼叫者、用户设备、呼叫者、紧急服务路由代理（ESRP）和公共安全应答点（PSAP）等术语。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
This section illustrates a number of scenarios where the currently specified solution, as described in [RFC6881], for preferential treatment of callbacks fails. As explained in Section 1, a SIP entity examines an incoming PSAP callback by comparing the domain of the PSAP with the destination domain of the outbound emergency call placed earlier.
本节说明了当前指定的优先处理回调的解决方案（如[RFC6881]中所述）失败的许多场景。如第1节所述，SIP实体通过比较PSAP的域与先前发出的出站紧急呼叫的目标域来检查传入PSAP回调。
In some deployment environments, it is common to have incoming and outgoing SIP messaging routed through different SIP entities. Figure 1 shows this graphically whereby a Voice over IP (VoIP) provider uses different SIP proxies for inbound and for outbound call handling. Unless the two devices are synchronized, the callback
在某些部署环境中，通过不同的SIP实体路由传入和传出SIP消息是很常见的。图1以图形方式显示了这一点，其中IP语音（VoIP）提供商使用不同的SIP代理来处理入站和出站呼叫。除非这两个设备是同步的，否则回调
reaching the inbound proxy would get treated like any other call since the emergency call established state information at the outbound proxy only.
到达入站代理将被视为与任何其他呼叫一样，因为紧急呼叫仅在出站代理上建立状态信息。
,-------.
,' `.
,-------. / Emergency \
,' `. | Services |
/ VoIP \ I | Network |
| Provider | n | |
| | t | |
| | e | |
| +-------+ | r | |
+--+---|Inbound|<--+-----m | |
| | |Proxy | | e | +------+ |
| | +-------+ | d | |PSAP | |
| | | i | +--+---+ |
+----+ | | | a-+ | | |
| UA |<---+ | | t | | | |
| |----+ | | e | | | |
+----+ | | | | | | |
| | | P | | | |
| | | r | | | |
| | +--------+ | o | | | |
+--+-->|Outbound|--+---->v | | +--+---+ |
| |Proxy | | i | | +-+ESRP | |
| +--------+ | d | | | +------+ |
| | e | | | |
| | r +----+-+ |
\ / | |
`. ,' \ /
'-------' `. ,'
'-------'
,-------.
,' `.
,-------. / Emergency \
,' `. | Services |
/ VoIP \ I | Network |
| Provider | n | |
| | t | |
| | e | |
| +-------+ | r | |
+--+---|Inbound|<--+-----m | |
| | |Proxy | | e | +------+ |
| | +-------+ | d | |PSAP | |
| | | i | +--+---+ |
+----+ | | | a-+ | | |
| UA |<---+ | | t | | | |
| |----+ | | e | | | |
+----+ | | | | | | |
| | | P | | | |
| | | r | | | |
| | +--------+ | o | | | |
+--+-->|Outbound|--+---->v | | +--+---+ |
| |Proxy | | i | | +-+ESRP | |
| +--------+ | d | | | +------+ |
| | e | | | |
| | r +----+-+ |
\ / | |
`. ,' \ /
'-------' `. ,'
'-------'
Figure 1: Example for Routing Asymmetry
图1：路由不对称的示例
Consider the emergency call routing scenario shown in Figure 2 where routing towards the PSAP occurs in several stages. In this scenario, we consider a SIP UA that uses the Location-to-Service Translation (LoST) Protocol [RFC5222] to learn the next-hop destination, namely esrp@example.net, to get the call closer to the PSAP. This call is then sent to the proxy of the user's VoIP provider (example.org). The user's VoIP provider receives the emergency call and creates a state based on the destination domain, namely example.net. It then routes the call to the indicated ESRP. When the ESRP receives the call, it needs to decide what the next hop is to get to the final PSAP. In our example, the next hop is the PSAP with the URI psap@example.com.
考虑急诊科呼叫路由方案，如图2所示，其中路由分阶段的PSAP发生在几个阶段。在这种情况下，我们考虑使用位置到服务翻译（丢失）协议[fcc5222]来学习下一跳目的地的SIP UA，即esrp@example.net，使电话更接近PSAP。然后将此呼叫发送到用户的VoIP提供商的代理（example.org）。用户的VoIP提供商接收紧急呼叫并基于目标域（即example.net）创建状态。然后将调用路由到指定的ESRP。当ESRP收到呼叫时，它需要决定到达最终PSAP的下一跳是什么。在我们的示例中，下一个跃点是带有URI的PSAPpsap@example.com.
When a callback is sent from psap@example.com towards the emergency caller, the call will get normal treatment by the proxy of the VoIP provider since the domain of the PSAP does not match the stored state information.
当从发送回调时psap@example.com对于紧急呼叫者，由于PSAP的域与存储的状态信息不匹配，呼叫将得到VoIP提供商的代理的正常处理。
,-----------.
+----+ ,' `.
| UA |--- esrp@example.net / Emergency \
+----+ \ | Services |
\ ,-------. | Network |
,' `. | |
/ VoIP \ | +------+ |
( Provider ) | | PSAP | |
\ example.org / | +--+---+ |
`. ,' | | |
'---+---' | | |
| | psap@example.com |
esrp@example.net | | |
| | | |
| | | |
| | +--+---+ |
+------------+-----+ ESRP | |
| +------+ |
| |
\ /
`. ,'
'----------'
,-----------.
+----+ ,' `.
| UA |--- esrp@example.net / Emergency \
+----+ \ | Services |
\ ,-------. | Network |
,' `. | |
/ VoIP \ | +------+ |
( Provider ) | | PSAP | |
\ example.org / | +--+---+ |
`. ,' | | |
'---+---' | | |
| | psap@example.com |
esrp@example.net | | |
| | | |
| | | |
| | +--+---+ |
+------------+-----+ ESRP | |
| +------+ |
| |
\ /
`. ,'
'----------'
Figure 2: Example for Multi-Stage Routing
图2：多级路由的示例
Imagine the following case where an emergency call enters an emergency network (state.example) via an ESRP, but then it gets forwarded to a different emergency services network (in our example, to example.net, example.org, or example.com). The same considerations apply when the police, fire and, ambulance networks are part of the state.example subdomains (e.g., police.state.example).
想象一下以下情况：紧急呼叫通过ESRP进入紧急网络（state.example），但随后被转发到不同的紧急服务网络（在我们的示例中，转发到example.net、example.org或example.com）。当警察、消防和救护车网络是state.example子域（例如police.state.example）的一部分时，同样的考虑也适用。
Similar to the previous scenario, the wrong state information is being set up during the emergency call setup procedure. A callback would originate in the example.net, example.org, or example.com domains whereas the emergency caller's SIP UA or the VoIP outbound proxy has stored state.example.
与前面的场景类似，在紧急呼叫设置过程中设置了错误的状态信息。回调将起源于example.net、example.org或example.com域，而紧急呼叫者的SIP UA或VoIP出站代理已存储state.example。
,-------.
,' `.
/ Emergency \
| Services |
| Network |
|(state.example)|
| |
| |
| +------+ |
| |PSAP +--+ |
| +--+---+ | |
| | | |
| | | |
| | | |
| | | |
| | | |
| +--+---+ | |
------------------+---+ESRP | | |
esrp-a@state.org | +------+ | |
| | |
| Call Fwd | |
| +-+-+---+ |
\ | | | /
`. | | | ,'
'-|-|-|-' ,-------.
Police | | | Fire ,' `.
+------------+ | +----+ / Emergency \
,-------. | | | | Services |
,' `. | | | | Network |
/ Emergency \ | Ambulance | | (Fire) |
| Services | | | | | |
| Network | | +----+ | | +------+ |
| (Police) | | ,-------. | +----+---+PSAP | |
| | | ,' `. | | +------+ |
| +------+ | | / Emergency \ | | |
| |PSAP +----+--+ | Services | | | example.com ,
| +------+ | | Network | | `~~~~~~~~~~~~~~~
| | | (Ambulance) | |
| example.net , | | |
`~~~~~~~~~~~~~~~ | +------+ | |
| |PSAP +----+ +
| +------+ |
| |
| example.org ,
`~~~~~~~~~~~~~~~
,-------.
,' `.
/ Emergency \
| Services |
| Network |
|(state.example)|
| |
| |
| +------+ |
| |PSAP +--+ |
| +--+---+ | |
| | | |
| | | |
| | | |
| | | |
| | | |
| +--+---+ | |
------------------+---+ESRP | | |
esrp-a@state.org | +------+ | |
| | |
| Call Fwd | |
| +-+-+---+ |
\ | | | /
`. | | | ,'
'-|-|-|-' ,-------.
Police | | | Fire ,' `.
+------------+ | +----+ / Emergency \
,-------. | | | | Services |
,' `. | | | | Network |
/ Emergency \ | Ambulance | | (Fire) |
| Services | | | | | |
| Network | | +----+ | | +------+ |
| (Police) | | ,-------. | +----+---+PSAP | |
| | | ,' `. | | +------+ |
| +------+ | | / Emergency \ | | |
| |PSAP +----+--+ | Services | | | example.com ,
| +------+ | | Network | | `~~~~~~~~~~~~~~~
| | | (Ambulance) | |
| example.net , | | |
`~~~~~~~~~~~~~~~ | +------+ | |
| |PSAP +----+ +
| +------+ |
| |
| example.org ,
`~~~~~~~~~~~~~~~
Figure 3: Example for Call Forwarding
图3：呼叫转移示例
The IETF emergency services architecture also considers cases where the resolution from the Service URN to the PSAP URI does not only happen at the SIP UA itself but at intermediate SIP entities, such as the user's VoIP provider.
IETF应急服务体系结构还考虑了从服务URN到PSAP URI的解析不仅发生在SIP UA本身，而且发生在中间SIP实体（如用户的VoIP提供商）的情况。
Figure 4 shows this message exchange of the outgoing emergency call and the incoming PSAP graphically. While the state information stored at the VoIP provider is correct, the state allocated at the SIP UA is not.
图4以图形方式显示了传出紧急呼叫和传入PSAP的消息交换。虽然存储在VoIP提供商处的状态信息是正确的，但是在SIP UA处分配的状态不是正确的。
,-------.
,' `.
/ Emergency \
| Services |
| Network |
| example.com |
| |
| +------+ | INVITE to police@example.com
| |PSAP +<---+------------------------+
| | +----+--------------------+ ^
| +------+ |INVITE from | |
| ,police@example.com | |
`~~~~~~~~~~~~~~~ | |
v |
+--------+ Query with location +--+---+-+
| | + urn:service:sos | VoIP |
| LoST |<-----------------------|Service |
| Server | police@example.com |Provider|
| |----------------------->| |
+--------+ +--------+
| ^
INVITE| | INVITE
from| | to
police@example.com| | urn:service:sos
V |
+-------+
| SIP |
| UA |
| Alice |
+-------+
,-------.
,' `.
/ Emergency \
| Services |
| Network |
| example.com |
| |
| +------+ | INVITE to police@example.com
| |PSAP +<---+------------------------+
| | +----+--------------------+ ^
| +------+ |INVITE from | |
| ,police@example.com | |
`~~~~~~~~~~~~~~~ | |
v |
+--------+ Query with location +--+---+-+
| | + urn:service:sos | VoIP |
| LoST |<-----------------------|Service |
| Server | police@example.com |Provider|
| |----------------------->| |
+--------+ +--------+
| ^
INVITE| | INVITE
from| | to
police@example.com| | urn:service:sos
V |
+-------+
| SIP |
| UA |
| Alice |
+-------+
Figure 4: Example for Network-Based Service URN Resolution
图4：基于网络的服务URN解析示例
In case an emergency call enters the Public Switched Telephone Network (PSTN), as shown in Figure 5, there is no guarantee that the callback sometime later leaves the same PSTN/VoIP gateway or that the same endpoint identifier is used in the forward as well as in the backward direction making it difficult to reliably detect PSAP callbacks.
在紧急呼叫进入公共交换电话网（PSTN）的情况下，如图5所示，无法保证回调稍后离开同一PSTN/VoIP网关，或者在正向和反向使用相同的端点标识符，从而难以可靠地检测PSAP回调。
+-----------+
| PSTN |-------------+
| Calltaker | |
| Bob |<--------+ |
+-----------+ | v
-------------------
//// \\\\ +------------+
| | |PSTN / VoIP |
| PSTN |---->|Gateway |
\\\\ //// | |
------------------- +----+-------+
^ |
| |
+-------------+ | +--------+
| | | |VoIP |
| PSTN / VoIP | +->|Service |
| Gateway | |Provider|
| |<------INVITE----| Y |
+-------------+ +--------+
| ^
| |
INVITE INVITE
| |
V |
+-------+
| SIP |
| UA |
| Alice |
+-------+
+-----------+
| PSTN |-------------+
| Calltaker | |
| Bob |<--------+ |
+-----------+ | v
-------------------
//// \\\\ +------------+
| | |PSTN / VoIP |
| PSTN |---->|Gateway |
\\\\ //// | |
------------------- +----+-------+
^ |
| |
+-------------+ | +--------+
| | | |VoIP |
| PSTN / VoIP | +->|Service |
| Gateway | |Provider|
| |<------INVITE----| Y |
+-------------+ +--------+
| ^
| |
INVITE INVITE
| |
V |
+-------+
| SIP |
| UA |
| Alice |
+-------+
Figure 5: Example for PSTN Interworking
图5:PSTN互通示例
Note: This scenario is considered outside the scope of this document. The specified solution does not support this use case.
注意：此场景不在本文档的范围内。指定的解决方案不支持此用例。
This section defines a new header field value, called "psap-callback", for the SIP Priority header field defined in [RFC3261]. The value is used to inform SIP entities that the request is associated with a PSAP callback SIP session.
本节为[RFC3261]中定义的SIP优先级报头字段定义了一个新的报头字段值，称为“psap回调”。该值用于通知SIP实体该请求与PSAP回调SIP会话关联。
SIP entities that receive the header field value within an initial request for a SIP session can, depending on local policies, apply PSAP callback-specific procedures for the session or request.
在SIP会话的初始请求中接收头字段值的SIP实体可以根据本地策略为会话或请求应用特定于PSAP回调的过程。
The PSAP callback-specific procedures may be applied by SIP-based network entities and by the callee. The specific actions taken when receiving a call marked as a PSAP callback marked call, such as bypassing services and barring procedures, are outside the scope of this document.
PSAP回调特定过程可由基于SIP的网络实体和被叫方应用。接收标记为PSAP回调标记调用的调用时所采取的特定操作，如绕过服务和禁止过程，不在本文档的范围内。
This section defines the ABNF [RFC5234] for the new SIP Priority header field value "psap-callback".
本节为新SIP优先级标头字段值“psap回调”定义ABNF[RFC5234]。
priority-value =/ "psap-callback"
优先级值=/“psap回调”
Figure 6: ABNF
图6:ABNF
The PSAP callback functionality described in this document allows marked calls to bypass blacklists and ignore call-forwarding procedures and other similar features used to raise the attention of emergency callers when attempting to contact them. In the case where the SIP Priority header value, "psap-callback", is supported by the SIP UA, it would override user-interface configurations, such as vibrate-only mode, to alert the caller of the incoming call.
本文档中描述的PSAP回调功能允许标记呼叫绕过黑名单，忽略呼叫转移过程和其他类似功能，这些功能用于在尝试联系紧急呼叫者时引起紧急呼叫者的注意。在SIP UA支持SIP优先级头值“psap回调”的情况下，它将覆盖用户界面配置，例如仅振动模式，以提醒呼叫者传入呼叫。
The security threat discussed in Section 5.1 leads to the requirement to ensure that the mechanisms described in this document cannot be used for malicious purposes, including telemarketing.
第5.1节中讨论的安全威胁要求确保本文件中描述的机制不能用于恶意目的，包括电话营销。
Furthermore, if the newly defined extension is not recognized, not verified adequately, or not obeyed by SIP intermediaries or SIP endpoints, then it must not lead to a failure of the call handling procedure. Such a call must be treated like a call that does not have any marking attached.
此外，如果新定义的扩展未被识别、未充分验证，或者SIP中介或SIP端点未遵守，则它不得导致呼叫处理过程失败。必须将此类呼叫视为未附加任何标记的呼叫。
The indicator described in Section 4 can be inserted by any SIP entity, including attackers. So it is critical that the indicator only lead to preferential call treatment in cases where the recipient has some trust in the caller, as described in the next section.
第4节中描述的指示器可由任何SIP实体插入，包括攻击者。因此，如下一节所述，只有在接收者对呼叫者有一定信任的情况下，指标才能导致优先呼叫处理，这一点至关重要。
The approach for dealing with the implementation of the security requirements described in Section 5.2 can be differentiated between the behavior applied by the UA and by SIP proxies. A UA that has made an emergency call MUST keep state information so that it can recognize and accept a callback from the PSAP if it occurs within a reasonable time after an emergency call was placed, as described in Section 13 of [RFC6443]. Only a timer started at the time when the original emergency call has ended is required; information about the calling party identity is not needed since the callback may use a different calling party identity, as described in Section 3. Since these SIP UA considerations are described already in [RFC6443] as well as in [RFC6881] the rest of this section focuses on the behavior of SIP proxies.
处理第5.2节中描述的安全要求的实现的方法可以在UA和SIP代理应用的行为之间进行区分。如[RFC6443]第13节所述，发出紧急呼叫的UA必须保留状态信息，以便在发出紧急呼叫后的合理时间内识别并接受PSAP的回调。仅需要在原始紧急呼叫结束时启动计时器；不需要关于主叫方标识的信息，因为回调可能使用不同的主叫方标识，如第3节所述。由于[RFC6443]和[RFC6881]中已经描述了这些SIP UA注意事项，因此本节的其余部分将重点介绍SIP代理的行为。
Figure 7 shows the architecture that utilizes the identity of the PSAP to decide whether a preferential treatment of callbacks should be provided. To make this policy decision, the identity of the PSAP (i.e., calling party identity) is compared with a PSAPs white list.
图7显示了利用PSAP的身份来决定是否应该提供回调优惠待遇的体系结构。为了做出此决策，将PSAP的标识（即主叫方标识）与PSAP白名单进行比较。
+----------+
| List of |+
| valid ||
| PSAPs ||
+----------+|
+----------+
*
* white list
*
V
Incoming +----------+ Normal
SIP Msg | SIP |+ Treatment
-------------->| Entity ||======================>
+ Identity | ||(if not in white list)
Info +----------+|
+----------+
||
||
|| Preferential
|| Treatment
++========================>
(if successfully verified)
+----------+
| List of |+
| valid ||
| PSAPs ||
+----------+|
+----------+
*
* white list
*
V
Incoming +----------+ Normal
SIP Msg | SIP |+ Treatment
-------------->| Entity ||======================>
+ Identity | ||(if not in white list)
Info +----------+|
+----------+
||
||
|| Preferential
|| Treatment
++========================>
(if successfully verified)
Figure 7: Identity-Based Authorization
图7：基于身份的授权
The identity assurance in SIP can come in different forms, namely via the SIP Identity [RFC4474] or the P-Asserted-Identity [RFC3325] mechanisms. The former technique relies on a cryptographic assurance and the latter on a chain of trust. Also, the usage of Transport Layer Security (TLS) between neighboring SIP entities may provide useful identity information. At the time of writing, these identity technologies are being revised in the Secure Telephone Identity Revisited (stir) working group [STIR] to offer better support for legacy technologies interworking and SIP intermediaries that modify the content of various SIP headers and the body. Once the work on these specifications has been completed, they will offer a stronger calling party identity mechanism that limits or prevents identity spoofing.
SIP中的身份保证可以有不同的形式，即通过SIP标识[RFC4474]或P-Asserted-identity[RFC3325]机制。前者依赖于加密保证，后者依赖于信任链。此外，相邻SIP实体之间的传输层安全性（TLS）的使用可以提供有用的身份信息。在撰写本文时，安全电话身份重访（stir）工作组[stir]正在对这些身份技术进行修订，以更好地支持修改各种SIP头和主体内容的传统技术互通和SIP中介。一旦这些规范的工作完成，它们将提供更强大的呼叫方身份机制，以限制或防止身份欺骗。
An important aspect from a security point of view is the relationship between the emergency services network (containing the PSAPs) and the VoIP provider, assuming that the emergency call travels via the VoIP provider and not directly between the SIP UA and the PSAP.
从安全角度来看，一个重要方面是紧急服务网络（包含PSAP）和VoIP提供商之间的关系，假设紧急呼叫通过VoIP提供商而不是直接在SIP UA和PSAP之间传输。
The establishment of a white list with PSAP identities may be operationally complex and dependent on the relationship between the emergency services operator and the VoIP provider. If there is a relationship between the VoIP provider and the PSAP operator, for
建立具有PSAP身份的白名单在操作上可能很复杂，并且取决于紧急服务运营商和VoIP提供商之间的关系。如果VoIP提供商和PSAP运营商之间存在关系，例如
example, when they are both operating in the same geographical region, then populating the white list is fairly simple and consequently the identification of a PSAP callback is less problematic compared to the case where the two entities have never interacted with each other before. In the end, the VoIP provider has to verify whether the marked callback message indeed came from a legitimate source.
例如，当两个实体都在同一地理区域内运行时，填充白名单相当简单，因此，与两个实体以前从未交互的情况相比，PSAP回调的识别问题更少。最后，VoIP提供商必须验证标记的回调消息是否确实来自合法来源。
VoIP providers MUST only give PSAP callbacks preferential treatment when the calling party identity of the PSAP was successfully matched against entries in the white list. If it cannot be verified (because there was no match), then the VoIP provider MUST remove the PSAP callback marking. Thereby, the callback reverts to a normal call. As a second step, SIP UAs MUST maintain a timer that is started with the original emergency call and this timer expires within a reasonable amount of time, such as 30 minutes per [RFC6881]. Such a timer also ensures that VoIP providers cannot misuse the PSAP callback mechanism, for example, to ensure that their support calls reach their customers.
只有当PSAP的主叫方身份与白名单中的条目成功匹配时，VoIP提供商才能给予PSAP回调优惠待遇。如果无法验证（因为不存在匹配项），则VoIP提供商必须删除PSAP回调标记。因此，回调恢复为正常调用。作为第二步，SIP UAs必须维护一个计时器，该计时器从原始紧急呼叫开始，并且该计时器在合理的时间内到期，例如每[RFC6881]30分钟。这样的计时器还可以确保VoIP提供商不会滥用PSAP回调机制，例如，以确保其支持呼叫到达其客户。
Finally, a PSAP callback MUST use the same media as the original emergency call. For example, when an initial emergency call established a real-time text communication session, then the PSAP callback must also attempt to establish a real-time communication interaction. The reason for this is twofold. First, the person seeking help may have disabilities that prevent them from using certain media and hence using the same media for the callback avoids unpleasant surprises and delays. Second, the emergency caller may have intentionally chosen a certain media and does not prefer to communicate in a different way. For example, it would be unfortunate if a hostage tries to seek help using instant messaging to avoid any noise when subsequently the ringtone triggered by a PSAP callback using a voice call gets the attention of the hostage-taker. User-interface designs need to cater to such situations.
最后，PSAP回调必须使用与原始紧急呼叫相同的介质。例如，当初始紧急呼叫建立实时文本通信会话时，PSAP回调还必须尝试建立实时通信交互。原因有两个。首先，寻求帮助的人可能有残疾，妨碍他们使用某些媒体，因此使用相同的媒体进行回调可以避免令人不快的意外和延迟。其次，紧急呼叫者可能故意选择了某种媒体，不喜欢以不同的方式进行沟通。例如，如果人质试图使用即时消息寻求帮助以避免任何噪音，而随后使用语音呼叫的PSAP回调触发的铃声引起了劫持人质者的注意，这将是不幸的。用户界面设计需要迎合这种情况。
This document adds the "psap-callback" value to the SIP "Priority Header Field Values" registry allocated by [RFC6878]. The semantic of the newly defined "psap-callback" value is defined in Section 4.
本文档将“psap回调”值添加到[RFC6878]分配的SIP“优先级头字段值”注册表中。第4节定义了新定义的“psap回调”值的语义。
We would like to thank the following persons for their feedback: Bernard Aboba, Andrew Allen, John-Luc Bakker, Kenneth Carlberg, Martin Dolly, Keith Drage, Timothy Dwight, John Elwell, Janet Gunn, Cullen Jennings, Hadriel Kaplan, Paul Kyzivat, John Medland, Atle Monrad, James Polk, Dan Romascanu, Brian Rosen, Robert Sparks, Geoff Thompson, and Martin Thomson.
我们要感谢以下人士的反馈：伯纳德·阿博巴、安德鲁·艾伦、约翰·吕克·巴克、肯尼斯·卡尔伯格、马丁·多利、基思·德雷格、蒂莫西·德怀特、约翰·埃尔威尔、珍妮特·冈恩、卡伦·詹宁斯、哈德里尔·卡普兰、保罗·基齐瓦特、约翰·梅德兰、阿特勒·蒙拉德、詹姆斯·波尔克、丹·罗马斯坎努、布莱恩·罗森、罗伯特·斯帕克斯、杰夫·汤普森、，还有马丁·汤姆森。
We would also like to thank the ECRIT working group chairs, Marc Linsner and Roger Marshall, for their support. Roger Marshall was the document shepherd for this document. Vijay Gurbani provided the general area review.
我们还要感谢ECRIT工作组主席马克·林斯纳（Marc Linsner）和罗杰·马歇尔（Roger Marshall）的支持。罗杰·马歇尔是这份文件的文件管理员。Vijay Gurbani提供了一般区域审查。
During IESG review, the document received good feedback from Barry Leiba, Spencer Dawkins, Richard Barnes, Joel Jaeggli, Stephen Farrell, and Benoit Claise.
在IESG审查期间，该文件收到了Barry Leiba、Spencer Dawkins、Richard Barnes、Joel Jaeggli、Stephen Farrell和Benoit Claise的良好反馈。
[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月。
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.，Ed.，和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol (SIP)", RFC 5627, October 2009.
[RFC5627]Rosenberg，J.，“在会话启动协议（SIP）中获取和使用全局可路由用户代理URI（GRUUs）”，RFC 5627，2009年10月。
[RFC6878] Roach, A., "IANA Registry for the Session Initiation Protocol (SIP) "Priority" Header Field", RFC 6878, March 2013.
[RFC6878]Roach，A.，“会话启动协议（SIP）的IANA注册表”优先级“头字段”，RFC 6878，2013年3月。
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002.
[RFC3325]Jennings，C.，Peterson，J.，和M.Watson，“在可信网络中声明身份的会话启动协议（SIP）的私有扩展”，RFC 33252002年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月。
[RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for Emergency Context Resolution with Internet Technologies", RFC 5012, January 2008.
[RFC5012]Schulzrinne，H.和R.Marshall，“利用互联网技术解决紧急情况的要求”，RFC 5012，2008年1月。
[RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. Tschofenig, "LoST: A Location-to-Service Translation Protocol", RFC 5222, August 2008.
[RFC5222]Hardie，T.，Newton，A.，Schulzrinne，H.，和H.Tschofenig，“丢失：位置到服务转换协议”，RFC 5222，2008年8月。
[RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, "Framework for Emergency Calling Using Internet Multimedia", RFC 6443, December 2011.
[RFC6443]Rosen，B.，Schulzrinne，H.，Polk，J.，和A.Newton，“使用互联网多媒体进行紧急呼叫的框架”，RFC 64432011年12月。
[RFC6881] Rosen, B. and J. Polk, "Best Current Practice for Communications Services in Support of Emergency Calling", BCP 181, RFC 6881, March 2013.
[RFC6881]Rosen，B.和J.Polk，“支持紧急呼叫的通信服务最佳现行实践”，BCP 181，RFC 6881，2013年3月。
[STIR] IETF, "Secure Telephone Identity Revisited (stir) Working Group", http://datatracker.ietf.org/wg/stir/charter/, October 2013.
[STIR]IETF，“重新访问安全电话身份（STIR）工作组”，http://datatracker.ietf.org/wg/stir/charter/，2013年10月。
Authors' Addresses
作者地址
Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 US
美国纽约州纽约市哥伦比亚大学计算机科学系计算机科学大楼450号
Phone: +1 212 939 7004
EMail: hgs+ecrit@cs.columbia.edu
URI: http://www.cs.columbia.edu
Phone: +1 212 939 7004
EMail: hgs+ecrit@cs.columbia.edu
URI: http://www.cs.columbia.edu
Hannes Tschofenig
汉内斯·乔菲尼
EMail: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
EMail: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420 Finland
Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420芬兰
EMail: christer.holmberg@ericsson.com
EMail: christer.holmberg@ericsson.com
Milan Patel Huawei Technologies (UK) Co., Ltd. 300 South Oak Way, Green Park Reading, Berkshire RG2 6UF U.K.
米兰帕特尔华为技术（英国）有限公司300南橡树路，绿色公园阅读，伯克希尔RG2 6UF英国
EMail: Milan.Patel@huawei.com
EMail: Milan.Patel@huawei.com