Internet Engineering Task Force (IETF) R. Atarius, Ed.
Request for Comments: 8465 September 2018
Category: Informational
ISSN: 2070-1721
Internet Engineering Task Force (IETF) R. Atarius, Ed.
Request for Comments: 8465 September 2018
Category: Informational
ISSN: 2070-1721
Using the Mobile Equipment Identity (MEID) URN as an Instance ID
使用移动设备标识（MEID）URN作为实例ID
Abstract
摘要
This document specifies how the Uniform Resource Name (URN) namespace reserved for the Third Generation Partnership Project 2 (3GPP2) identities and its Namespace Specific String (NSS) for the Mobile Equipment Identity (MEID) can be used as an Instance ID. The purpose of this Instance ID is to fulfill the requirements for defining how a specific URN needs to be constructed and used in the "+sip.instance" Contact header field parameter for outbound behavior.
本文档规定了为第三代合作伙伴关系项目2（3GPP2）标识保留的统一资源名称（URN）命名空间及其为移动设备标识（MEID）保留的命名空间特定字符串（NSS）的方式可以用作实例ID。此实例ID的目的是满足定义特定URN需要如何构造和在出站行为的“+sip.Instance”联系人标头字段参数中使用的要求。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
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). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8465.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8465.
Copyright Notice
版权公告
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2018 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. 3GPP2 Use Cases . . . . . . . . . . . . . . . . . . . . . . . 4
5. User Agent Client Procedures . . . . . . . . . . . . . . . . 5
6. User Agent Server Procedures . . . . . . . . . . . . . . . . 5
7. 3GPP/3GPP2 SIP Registrar Procedures . . . . . . . . . . . . . 5
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
9. Security Considerations . . . . . . . . . . . . . . . . . . . 6
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
10.1. Normative References . . . . . . . . . . . . . . . . . . 7
10.2. Informative References . . . . . . . . . . . . . . . . . 8
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. 3GPP2 Use Cases . . . . . . . . . . . . . . . . . . . . . . . 4
5. User Agent Client Procedures . . . . . . . . . . . . . . . . 5
6. User Agent Server Procedures . . . . . . . . . . . . . . . . 5
7. 3GPP/3GPP2 SIP Registrar Procedures . . . . . . . . . . . . . 5
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
9. Security Considerations . . . . . . . . . . . . . . . . . . . 6
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
10.1. Normative References . . . . . . . . . . . . . . . . . . 7
10.2. Informative References . . . . . . . . . . . . . . . . . 8
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8
This document specifies how the Uniform Resource Name (URN) namespace reserved for Third Generation Partnership Project 2 (3GPP2) identities and its Namespace Specific String (NSS) for the Mobile Equipment Identity (MEID) as specified in RFC 8464 [10] can be used as an Instance ID as specified in RFC 5626 [4] and also as used by RFC 5627 [5].
本文档规定了为第三代合作伙伴关系项目2（3GPP2）标识保留的统一资源名称（URN）命名空间以及RFC 8464[10]中指定的移动设备标识（MEID）的命名空间特定字符串（NSS）如何用作RFC 5626[4]中指定的实例ID，以及RFC 5627[5]所使用的实例ID。
RFC 5626 [4] specifies the "+sip.instance" Contact header field parameter that contains a URN as specified in RFC 8141 [6]. The Instance ID uniquely identifies a specific User Agent (UA) instance. This Instance ID is used as specified in RFC 5626 [4] so that the Session Initiation Protocol (SIP) registrar (as specified in RFC 3261 [2]) can recognize that the contacts from multiple registrations correspond to the same UA. The Instance ID is also used as specified by RFC 5627 [5] to create Globally Routable User Agent URIs (GRUUs) that can be used to uniquely address a UA when multiple UAs are registered with the same Address of Record (AoR).
RFC 5626[4]指定包含RFC 8141[6]中指定的URN的“+sip.instance”联系人标头字段参数。实例ID唯一标识特定的用户代理（UA）实例。按照RFC 5626[4]中的规定使用该实例ID，以便会话发起协议（SIP）注册器（按照RFC 3261[2]中的规定）能够识别来自多个注册的联系人对应于同一UA。实例ID还按照RFC 5627[5]的规定用于创建全局可路由用户代理URI（GRUU），当多个UA使用相同的记录地址（AoR）注册时，该URI可用于唯一寻址UA。
RFC 5626 [4] requires that a UA SHOULD create a Universally Unique Identifier (UUID) URN as specified in RFC 4122 [9] as its Instance ID but allow for the possibility to use other URN schemes.
RFC 5626[4]要求UA应创建RFC 4122[9]中指定的通用唯一标识符（UUID）URN作为其实例ID，但允许使用其他URN方案。
RFC 5626 [4] states:
RFC 5626[4]指出：
If a URN scheme other than UUID is used, the UA MUST only use URNs for which an RFC (from the IETF stream) defines how the specific URN needs to be constructed and used in the "+sip.instance" Contact header field parameter for outbound behavior.
如果使用UUID以外的URN方案，UA必须仅使用RFC（来自IETF流）定义如何构造特定URN并在“+sip.instance”联系人标头字段参数中用于出站行为的URN。
This specification meets this requirement by specifying how the 3GPP2 MEID URN is used in the "+sip.instance" Contact header field parameter for outbound behavior and RFC 8464 [10] specifies how the 3GPP2 MEID URN is constructed.
本规范通过指定3GPP2 MEID URN如何在出站行为的“+sip.instance”联系人标头字段参数中使用，以及RFC 8464[10]指定3GPP2 MEID URN如何构造，满足了这一要求。
The 3GPP2 MEID URN is a URN for the MEID a globally unique identifier that identifies mobile devices used in the 3GPP2 networks. The MEID allocation is managed by the 3GPP2 to ensure that the MEID values are globally unique. Details of the formatting of the MEID as a URN are specified in RFC 8464 [10] and the definition of the MEID is contained in 3GPP2 S.R0048-A [13].
3GPP2 MEID URN是MEID的URN，是标识3GPP2网络中使用的移动设备的全局唯一标识符。MEID分配由3GPP2管理，以确保MEID值是全局唯一的。作为URN的MEID格式的详细信息在RFC 8464[10]中规定，MEID的定义包含在3GPP2 S.R0048-a[13]中。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [1] [7] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[1][7]中所述进行解释。
Mobile communication has been rapidly improved from low-bit-rate circuit-switched systems to the higher-data-rate packet-switched system. The packet-switched system has added the mobile capability of Internet Protocol (IP) connectivity; thereby, the IP Multimedia Subsystem (IMS) have made SIP-based calls and IP multimedia sessions from mobile devices possible.
移动通信已经从低比特率的电路交换系统迅速发展到高数据速率的分组交换系统。分组交换系统增加了互联网协议（IP）连接的移动能力；因此，IP多媒体子系统（IMS）使得来自移动设备的基于SIP的呼叫和IP多媒体会话成为可能。
3GPP2 defines High Rate Packet Data (HRPD) with high data rates, and it dispenses with the 1x Circuit Switched (1xCS) infrastructure. This means that with HRPD networks, voice calls will need to be conducted using IP and IMS. However, SIP-based IMS networks will take a great many years from the time of writing to transition to the use of all IP; mobile devices will need to operate in both IP/SIP/IMS mode and circuit-switched mode. This means that calls and sessions will need to be handed over between IP/SIP/IMS mode and circuit-switched mode mid-call or mid-session. To achieve this, the mobile device needs to simultaneously communicate via both the IP/SIP/IMS domain and the circuit-switched domain.
3GPP2定义了具有高数据速率的高速分组数据（HRPD），并且它免除了1x电路交换（1xCS）基础设施。这意味着，在HRPD网络中，语音呼叫将需要使用IP和IMS进行。然而，基于SIP的IMS网络从编写之时到过渡到使用全IP需要很多年的时间；移动设备需要在IP/SIP/IMS模式和电路交换模式下运行。这意味着呼叫和会话需要在IP/SIP/IMS模式和电路交换模式中间呼叫或中间会话之间切换。为了实现这一点，移动设备需要同时经由IP/SIP/IMS域和电路交换域进行通信。
To meet this need, 3GPP2 has specified how to maintain voice-session continuity between the IP/SIP/IMS domain and the circuit-switched domain in 3GPP2 S.X0042-A [14].
为了满足这一需求，3GPP2在3GPP2 S.X0042-A[14]中规定了如何保持IP/SIP/IMS域和电路交换域之间的语音会话连续性。
In order for the mobile device to access SIP/IMS voice service via the circuit-switched domain, 3GPP2 has specified that a Mobile Switching Center (MSC) server will control mobile voice call setup
为了使移动设备经由电路交换域访问SIP/IMS语音服务，3GPP2已经指定移动交换中心（MSC）服务器将控制移动语音呼叫设置
over the circuit-switched radio access while establishing the corresponding voice session in the core network using SIP/IMS. The specified MSC server operates either via an IMS Media Gateway Control Function (MGCF) or directly if it is enhanced by SIP interface. To enable this, the mobile device MUST be identified in both the 1xCS and IP/SIP/IMS domains. The only mobile device identifier that is transportable using 1xCS signaling is the MEID; therefore, the Instance ID included by the MGCF or the MSC server and the Instance ID directly included by the mobile device both need to be based on the MEID.
通过电路交换无线电接入，同时使用SIP/IMS在核心网络中建立相应的语音会话。指定的MSC服务器通过IMS媒体网关控制功能（MGCF）或直接（如果通过SIP接口增强）运行。为了实现这一点，必须在1xCS和IP/SIP/IMS域中识别移动设备。使用1xCS信令可传输的唯一移动设备标识符是MEID；因此，MGCF或MSC服务器包括的实例ID和移动设备直接包括的实例ID都需要基于MEID。
Additionally in order to meet the above requirements, the same MEID that is obtained from the circuit-switched signaling by the MSC server needs to be obtainable from SIP signaling so that it can be determined that both the SIP signaling and circuit-switched signaling originate from the same mobile device.
另外，为了满足上述要求，MSC服务器从电路交换信令获得的相同MEID需要可以从SIP信令获得，以便可以确定SIP信令和电路交换信令两者都来自相同的移动设备。
1. The mobile device includes its MEID in the SIP REGISTER request so that the SIP registrar can perform a check of the Equipment Identity Register (EIR) to verify if this mobile device is allowed or barred from accessing the network for non-emergency services (e.g., because it has been stolen). If the mobile device is not allowed to access the network for non-emergency services, the SIP registrar can reject the registration. Thus, a barred mobile device is prevented from accessing the network for non-emergency services.
1. 移动设备在SIP注册请求中包括其MEID，以便SIP注册器可以执行对设备标识注册器（EIR）的检查，以验证该移动设备是否被允许或禁止访问用于非紧急服务的网络（例如，因为它已被盗）。如果不允许移动设备访问网络进行非紧急服务，SIP注册器可以拒绝注册。因此，禁止移动设备访问用于非紧急服务的网络。
2. The mobile device includes its MEID in SIP INVITE requests used to establish emergency sessions. This is so that the Public Safety Answering Point (PSAP) can obtain the MEID of the mobile device for identification purposes if required by regulations.
2. 移动设备在用于建立紧急会话的SIP INVITE请求中包含其MEID。这是为了公共安全应答点（PSAP）可以获得移动设备的MEID，以便在法规要求时进行识别。
3. The inclusion by the mobile device of its MEID in SIP INVITE requests used to establish emergency sessions is also used in the cases of unauthenticated emergency sessions to enable the network to identify the mobile device. This is especially important if the unauthenticated emergency session is handed over from the packet-switched domain to the circuit-switched domain. In this scenario, the MEID is the only identifier that is common to both domains. The Emergency Access Transfer Function (EATF), which coordinates the call transfer between the domains, can thus use the MEID to identify that the circuit-switched call is from the same mobile device that was in the emergency session in the packet-switched domain.
3. 移动设备在用于建立紧急会话的SIP INVITE请求中包含其MEID也用于未经验证的紧急会话，以使网络能够识别移动设备。如果未经验证的紧急会话从分组交换域转移到电路交换域，这一点尤为重要。在这种情况下，MEID是两个域共用的唯一标识符。因此，协调域之间呼叫转移的紧急接入转移功能（EATF）可以使用MEID来识别电路交换呼叫来自分组交换域中处于紧急会话中的同一移动设备。
A single mode 3GPP2 User Agent Client (UAC), which uses only 3GPP2 technology to transmit and receive voice or data, has an MEID as specified in 3GPP2 S.R0048-A [13]. The single mode 3GPP2 UAC that is registering with a 3GPP2 IMS network includes in the "sip.instance" media feature tag the 3GPP2 MEID URN according to the syntax specified in RFC 8464 [10] when performing the registration procedures specified in RFC 5626 [4] or RFC 5627 [5] (or any other procedure requiring the inclusion of the "sip.instance" media feature tag).
仅使用3GPP2技术发送和接收语音或数据的单模3GPP2用户代理客户端（UAC）具有3GPP2 S.R0048-A[13]中规定的MEID。在执行RFC 5626[4]或RFC 5627[5]中指定的注册过程（或要求包含“sip.instance”的任何其他过程）时，正在向3GPP2 IMS网络注册的单模3GPP2 UAC根据RFC 8464[10]中指定的语法在“sip.instance”媒体特征标签中包括3GPP2 MEID URN媒体功能标签）。
A UAC MUST NOT use the 3GPP2 MEID URN as an Instance ID except when registering with a 3GPP2 IMS network. When a UAC is operating in IMS mode, it will obtain the domain of the carrier's IMS network to register with, from the Universal Integrated Circuit Card (UICC), preconfiguration, or the network at the time of establishing the Packet Data Protocol (PDP) context. These three methods are carrier specific and are only performed by the carrier IMS networks. The UAC will also obtain the address of the IMS edge proxy to send the REGISTER request containing the MEID using information elements in the Attach response when it attempts to connect to the carrier's packet data network. When registering with a non-3GPP or non-3GPP2 IMS network, a UAC SHOULD use a UUID as an Instance ID as specified in RFC 5626 [4].
UAC不得将3GPP2 MEID URN用作实例ID，除非在3GPP2 IMS网络中注册。当UAC在IMS模式下运行时，它将在建立分组数据协议（PDP）上下文时，从通用集成电路卡（UICC）、预配置或网络获得运营商IMS网络的域以进行注册。这三种方法是特定于运营商的，仅由运营商IMS网络执行。UAC还将获得IMS边缘代理的地址，以便在尝试连接到运营商的分组数据网络时，使用附加响应中的信息元素发送包含MEID的注册请求。当向非3GPP或非3GPP2 IMS网络注册时，UAC应使用UUID作为RFC 5626[4]中指定的实例ID。
A UAC MUST NOT include the "sip.instance" media feature tag containing the 3GPP2 MEID URN in the Contact header field of non-REGISTER requests except when the request is related to an emergency session. Regulations can require that the MEID be provided to the PSAP. Any future exceptions to this prohibition require an RFC that addresses how privacy is not violated by such usage.
UAC不得在非注册请求的联系人标头字段中包含包含3GPP2 MEID URN的“sip.instance”媒体功能标签，除非该请求与紧急会话相关。法规可能要求向PSAP提供MEID。该禁令的任何未来例外要求RFC解决此类使用如何不侵犯隐私的问题。
A User Agent Server (UAS) MUST NOT include its "sip.instance" media feature tag containing the 3GPP2 MEID URN in the Contact header field of responses except when the response is related to an emergency session. Regulations can require the MEID to be provided to the PSAP. Any future exceptions to this prohibition require an RFC that addresses how privacy is not violated by such usage.
用户代理服务器（UAS）不得在响应的联系人标头字段中包含其包含3GPP2 MEID URN的“sip.instance”媒体功能标签，除非响应与紧急会话相关。法规可能要求向PSAP提供MEID。该禁令的任何未来例外要求RFC解决此类使用如何不侵犯隐私的问题。
In 3GPP/3GPP2 IMS, when the SIP Registrar receives in the Contact header field a "sip.instance" media feature tag containing the 3GPP2 MEID URN according to the syntax specified in RFC 8464 [10], the SIP registrar follows the procedures specified in RFC 5626 [4]. The MEID
在3GPP/3GPP2 IMS中，当SIP注册器根据RFC 8464[10]中指定的语法在联系人报头字段中接收到包含3GPP2 MEID URN的“SIP.instance”媒体特征标签时，SIP注册器遵循RFC 5626[4]中指定的过程。梅德
URN MAY be validated as described in the RFC 8464 [10]. If the UA indicates that it supports the extension in RFC 5627 [5] and the SIP Registrar allocates a GRUU according to the procedures specified in RFC 5627 [5], the Instance ID MUST be obfuscated when creating the "gr" parameter in order not to reveal the MEID to other UAs when the public GRUU is included in non-REGISTER requests and responses. 3GPP TS 24.229 [11] subclause 5.4.7A.2 specifies the mechanism for obfuscating the MEID when creating the "gr" parameter.
URN可按照RFC 8464[10]中所述进行验证。如果UA表示支持RFC 5627[5]中的扩展，并且SIP注册器根据RFC 5627[5]中指定的过程分配GRUU，则在创建“gr”参数时必须混淆实例ID，以便在非注册请求和响应中包含公共GRUU时不会将MEID透露给其他UA。3GPP TS 24.229[11]子条款5.4.7A.2规定了在创建“gr”参数时混淆MEID的机制。
This document has no IANA actions.
本文档没有IANA操作。
Since MEIDs, like other formats of Instance IDs, can be correlated to a user, they are personally identifiable information and MUST be treated as such. In particular, the "sip.instance" media feature tag containing the 3GPP2 MEID URN MUST NOT be included in requests or responses intended to convey any level of anonymity, as this could violate the user's privacy. RFC 5626 [4] states:
由于MEID与实例ID的其他格式一样，可以与用户关联，因此它们是个人可识别信息，必须如此对待。具体而言，包含3GPP2 MEID URN的“sip.instance”媒体特征标签不得包含在旨在传达任何匿名级别的请求或响应中，因为这可能侵犯用户的隐私。RFC 5626[4]指出：
One case where a UA could prefer to omit the "sip.instance" media feature tag is when it is making an anonymous request or some other privacy concern requires that the UA not reveal its identity.
UA可能更愿意省略“sip.instance”媒体功能标签的一种情况是，当UA发出匿名请求或其他隐私问题时，UA不需要透露其身份。
The same concerns apply when using the 3GPP2 MEID URN as an Instance ID. Publication of the 3GPP2 MEID URN to networks that the UA is not attached to or the UA does not have a service relationship with is a security breach; the "sip.instance" media feature tag MUST NOT be forwarded by the service provider's network elements when forwarding requests or responses towards the destination UA. The 3GPP2 MEID URN MUST NOT accidentally leak in other contexts, such as and in particular when application servers subscribe to user registration state using the event package defined in RFC 3680 [3]. Additionally, an Instance ID containing the 3GPP2 MEID URN identifies a mobile device and not a user. The Instance ID containing the 3GPP2 MEID URN MUST NOT be used alone as an address for a user or as an identification credential for a user. The GRUU mechanism specified in RFC 5627 [5] provides a means to create URIs that address the user at a specific device or UA.
当使用3GPP2 MEID URN作为实例ID时，同样的担忧也适用。将3GPP2 MEID URN发布到UA未连接或UA没有服务关系的网络是安全违规；当向目标UA转发请求或响应时，服务提供商的网络元素不得转发“sip.instance”媒体功能标签。3GPP2 MEID URN不得在其他上下文中意外泄漏，例如尤其是当应用服务器使用RFC 3680[3]中定义的事件包订阅用户注册状态时。此外，包含3GPP2 MEID URN的实例ID标识移动设备而不是用户。包含3GPP2 MEID URN的实例ID不能单独用作用户的地址或用户的身份凭证。RFC 5627[5]中指定的GRUU机制提供了一种创建URI的方法，该URI在特定设备或UA上向用户寻址。
Entities that log the Instance ID need to protect them as personally identifiable information. Regulations can require carriers to log SIP MEIDs.
记录实例ID的实体需要将其作为个人可识别信息进行保护。法规可能要求运营商记录SIP MEID。
In order to protect the "sip.instance" media feature tag containing the 3GPP2 MEID URN from being tampered with, those REGISTER requests containing the 3GPP2 MEID URN MUST be sent using a security mechanism such as Transport Layer Security (TLS) as specified in RFC 8446 [8] or any other security mechanism that provides equivalent levels of protection such as hop-by-hop security based upon IP Security (IPsec).
为了保护包含3GPP2 MEID URN的“sip.instance”媒体功能标签不被篡改，必须使用RFC 8446[8]中规定的传输层安全（TLS）等安全机制发送包含3GPP2 MEID URN的那些注册请求或提供同等保护级别的任何其他安全机制，如基于IP安全的逐跳安全（IPsec）。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <https://www.rfc-editor.org/info/rfc3261>.
[2] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，DOI 10.17487/RFC3261，2002年6月<https://www.rfc-editor.org/info/rfc3261>.
[3] Rosenberg, J., "A Session Initiation Protocol (SIP) Event Package for Registrations", RFC 3680, DOI 10.17487/RFC3680, March 2004, <https://www.rfc-editor.org/info/rfc3680>.
[3] Rosenberg，J.，“用于注册的会话启动协议（SIP）事件包”，RFC 3680，DOI 10.17487/RFC3680，2004年3月<https://www.rfc-editor.org/info/rfc3680>.
[4] Jennings, C., Ed., Mahy, R., Ed., and F. Audet, Ed., "Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)", RFC 5626, DOI 10.17487/RFC5626, October 2009, <https://www.rfc-editor.org/info/rfc5626>.
[4] Jennings，C.，Ed.，Mahy，R.，Ed.，和F.Audet，Ed.，“在会话启动协议（SIP）中管理客户端启动的连接”，RFC 5626，DOI 10.17487/RFC56262009年10月<https://www.rfc-editor.org/info/rfc5626>.
[5] Rosenberg, J., "Obtaining and Using Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol (SIP)", RFC 5627, DOI 10.17487/RFC5627, October 2009, <https://www.rfc-editor.org/info/rfc5627>.
[5] Rosenberg，J.，“在会话启动协议（SIP）中获取和使用全局可路由用户代理URI（GRUUs）”，RFC 5627，DOI 10.17487/RFC5627，2009年10月<https://www.rfc-editor.org/info/rfc5627>.
[6] Saint-Andre, P. and J. Klensin, "Uniform Resource Names (URNs)", RFC 8141, DOI 10.17487/RFC8141, April 2017, <https://www.rfc-editor.org/info/rfc8141>.
[6] Saint Andre，P.和J.Klensin，“统一资源名称（URN）”，RFC 8141，DOI 10.17487/RFC81412017年4月<https://www.rfc-editor.org/info/rfc8141>.
[7] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[7] Leiba，B.“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[8] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.
[8] Rescorla，E.，“传输层安全（TLS）协议版本1.3”，RFC 8446，DOI 10.17487/RFC8446，2018年8月<https://www.rfc-editor.org/info/rfc8446>.
[9] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, DOI 10.17487/RFC4122, July 2005, <https://www.rfc-editor.org/info/rfc4122>.
[9] Leach，P.，Mealling，M.和R.Salz，“通用唯一标识符（UUID）URN名称空间”，RFC 4122，DOI 10.17487/RFC4122，2005年7月<https://www.rfc-editor.org/info/rfc4122>.
[10] Atarius, R., "A URN Namespace for Device Identity and Mobile Equipment Identity (MEID)", RFC 8464, DOI 10.17487/RFC8464, September 2018, <https://www.rfc-editor.org/info/rfc8464>.
[10] Atarius，R.，“设备标识和移动设备标识（MEID）的URN名称空间”，RFC 8464，DOI 10.17487/RFC8464，2018年9月<https://www.rfc-editor.org/info/rfc8464>.
[11] 3GPP, "IP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3", 3GPP 24.229, Version 10.13.0, Release 10, September 2013, <ftp://ftp.3gpp.org/Specs/archive/24_series/24.229/>.
[11] 3GPP，“基于会话发起协议（SIP）和会话描述协议（SDP）的IP多媒体呼叫控制协议；第3阶段”，3GPP 24.229，版本10.13.0，版本10，2013年9月发布<ftp://ftp.3gpp.org/Specs/archive/24_series/24.229/>.
[12] Allen, A., Ed., "Using the International Mobile station Equipment Identity (IMEI) Uniform Resource Name (URN) as an Instance ID", RFC 7255, DOI 10.17487/RFC7255, May 2014, <https://www.rfc-editor.org/info/rfc7255>.
[12] Allen，A.，Ed.，“使用国际移动站设备标识（IMEI）统一资源名（URN）作为实例ID”，RFC 7255，DOI 10.17487/RFC7255，2014年5月<https://www.rfc-editor.org/info/rfc7255>.
[13] 3GPP2, "3G Mobile Equipment Identifier (MEID) - Stage 1, Version 4.0", Stage 1, Version 4.0, 3GPP2 S.R0048-A, June 2005.
[13] 3GPP2，“3G移动设备标识符（MEID）-第1阶段，版本4.0”，第1阶段，版本4.0，3GPP2 S.R0048-A，2005年6月。
[14] 3GPP2, "Voice Call Continuity between IMS and Circuit Switched Systems - Version 1.0", Version 1.0, 3GPP2 S.X0042-A 1.0, August 2008, <https://www.3gpp2.org/Public_html/Specs/ X.S0042-A_v1.0_080904.pdf>.
[14] 3GPP2，“IMS和电路交换系统之间的语音呼叫连续性-版本1.0”，版本1.0，3GPP2 S.X0042-A 1.0，2008年8月<https://www.3gpp2.org/Public_html/Specs/ X.S0042-A_v1.0_080904.pdf>。
Acknowledgments
致谢
This document draws heavily on RFC 8464 [10] and also on the style and structure used in RFC 7255 [12].
本文件大量借鉴了RFC 8464[10]以及RFC 7255[12]中使用的样式和结构。
The author thanks Andrew Allen for the detailed comments.
作者感谢安德鲁·艾伦的详细评论。
Author's Address
作者地址
Roozbeh Atarius (editor)
鲁兹贝·阿塔里斯（编辑）
Email: ratarius@motorola.com
Email: ratarius@motorola.com